Для прототипов и одноразовых проектов:
— наклепать нужный функционал сможет вчерашний студент за дешево
— поддерживать код не нужно, при необходимости дешевле переписать с нуля
А как только прототип есть и есть положительные отзывы, то можно браться за разработку «с умом», вводить всякие абстракции и т.п.
Но посудите сами, многие веб проекты написанные на коленке вполне себе работают и приносят деньги, так зачем идти против системы и пытаться продать то, что никому не нужно?
tel:// это далеко не самая «advanced» фича. Разработчики о ней знают.
Скорее это прекрасный пример отвратительного QA и низкоквалифицированной разработки конкретного продукта.
Единый стиль кода эта такая вещь, которая и вопросов вызывать не должна.
Я скорее имел в виду комплексные ограничения. Например, использование только делегатов или только коллбэков. Или вообще используем обмен сообщениями через какие-нибудь inter-thread сокеты ZeroMQ.
К сожалению Python очень непостоянный в этом плане язык. Ситуация, конечно, меняется от версии к версии, но разрыв шаблона при работе с разными встроенными библиотеками периодически происходит.
Лично я в первую очередь бы хотел видеть постоянство на протяжении языка и всей стандартной и де-факто стандартных библиотек. Вопросы производительности, безусловно важные, но не критичные для Python, языка, который более всего подходит для связывания различных компонент, описания логики взаимодействия.
Но при написании проектов в команде разве вы не вводите какие-то искусственные ограничения, чтобы выдержать весь код в одном стиле? Искусственные, а тем более явные ограничения позволяют более точно анализировать (в т.ч. автоматически) поведение программы.
Неправда. Хороший фрэймворк позволяет эффективно работать с собственной структурой и предусматривает возможность «вклиниться» в критичных местах. У данного фреймворка логика биндингов критична и непонятно можно в нее вклиниться или нет.
Вопрос в том, на каком уровне будет баг. Если фреймворк все взаимодействие берет на себя, то влезть и поправить будет намного сложнее, чем свой собственный код.
То есть контролируемая и исправимая ошибка вида «разработчик на месте забыл повесить обработчик» перетекает в «разработчик фреймворка допустил ошибку в коде биндинга», которые решаются только с помощью дичайших хаков?
Блеск! Гонять тесты вычисления случайных чисел при импорте — это сильно. Самое главное, надёжно. Вдруг /dev/urandom, шутник, будет возвращать не случайные числа — тесты не пройдут! Остается заметить, что import random делают Tornado, Twisted, uuid, и целая куча других библиотек, стандартных и не очень.
Тест будет выполнен не при иморте, а при выполнении этого модуля т.е. python random.py.
Учитывая требования и возможности языка он очень даже лаконичен. Ну сравните например с костылями в ObjC в виде переопределения всех переменных с ключевым словом __block для измнения правил передачи. Или разнообразные global и local в python.
Воспринимайте это как «low-level». Видить такой код (при качественной организации архитектуры) вы должны не чаще, чем заглядывать в исходники CPython, CRuby или node.js.
Ну понятно, чуда от кроссплатформенного решения ждать не приходится. Так или иначе, приходится реализовывать только те функции, которые общеие для всех поддерживаемых платформ, т.е. Qt предоставляет меньший функционал чем нативные средства by design.
— наклепать нужный функционал сможет вчерашний студент за дешево
— поддерживать код не нужно, при необходимости дешевле переписать с нуля
А как только прототип есть и есть положительные отзывы, то можно браться за разработку «с умом», вводить всякие абстракции и т.п.
Но посудите сами, многие веб проекты написанные на коленке вполне себе работают и приносят деньги, так зачем идти против системы и пытаться продать то, что никому не нужно?
Скорее это прекрасный пример отвратительного QA и низкоквалифицированной разработки конкретного продукта.
Я скорее имел в виду комплексные ограничения. Например, использование только делегатов или только коллбэков. Или вообще используем обмен сообщениями через какие-нибудь inter-thread сокеты ZeroMQ.
К сожалению Python очень непостоянный в этом плане язык. Ситуация, конечно, меняется от версии к версии, но разрыв шаблона при работе с разными встроенными библиотеками периодически происходит.
Лично я в первую очередь бы хотел видеть постоянство на протяжении языка и всей стандартной и де-факто стандартных библиотек. Вопросы производительности, безусловно важные, но не критичные для Python, языка, который более всего подходит для связывания различных компонент, описания логики взаимодействия.
Тест будет выполнен не при иморте, а при выполнении этого модуля т.е. python random.py.
Лично я имел дело с лямбдами только когда писал приложение для gstreamer. Лямбды были исключительно удобны в качестве замены коллбэкам.
Существуют ситуации, когда необходимо явно указывать все что можно, везде где можно. И эту возможность C++ предоставляет.
Это замечание справедливо и для оконной системы OSX, т.е. решение ниразу не кроссплатформенное (если предположить, что оно хоть где-то работает).