Не знаю, имеет ли смысл углубляться в дебри для приложения чуть сложнее чем персональная страничка. Тем более, что Flask. Bottle, etc — не зря называются микрофреймворками. Они собственно только и делаю, что прячут «дебри», и «наворачивают» не так сильно всего, как полные фреймворки. Если переводить на пиэчпишные понятия, то они скорее коррелируют в этом плане со Silex. При желании довести их до уровня Symfony2 возможно написанием расширений. Хотя уровень Symfony2 «из коробки» в питоне тоже представлен, это например Django.
Популярные микро и не очень фреймворки Flask, Bottle, Pyramid и т.д. используют этот подход, чем серьезно улучшают качество жизни python веб-программистов)
Вы собственно говоря и выразили расхожую мысль этих самых «новых менеджеров») Забыв при этом, что проект на который вас пригласили с хорошей зарплатой, как раз и поднялся на плечах тех кого вы охарактеризовали как «стариками-интровертами, цепляющимися за какие то древние мысли и темы, и претендующие на всезнание и всеведение».
Дай бог, что бы вы смогли принести новую свежую струю в этот проект, а не помогли похоронить его)
И да, физический возраст «старичка», тут не играет роли.
По моему вопрос не в том хороша или плоха MongoDB? И да же не в том права ли Сара? А в том, что в серьезном проекте вряд ли обойтись без транзакций и реляционных данных (финансы). А те фичи что дает MongoDB, сейчас во многом доступны например в PostgreSQL, даже MySQL пытается предложить похожий функционал.
Вопрос в том, стоит ли заводить вторую БД (MongoDB, etc) для нереляционных фишек? Если бы это давало прирост производительности в разы — то да, если нет — то нет :)
Я думаю очень ожидаема и интересная статья сравнивающая нереляционные фишки PostgreSQL с MongoDB. Во всяком случае это будет действительно интересно для тех, кто сейчас выбирает платформу под проект. А права ли Сара? NBC.
Вероятно, дальше мы увидим их мощь когда задача осложнится событиями кроме таймера.
Безусловно, например когда мы будем останавливать выполнение короутины для ожидания готовности сетевого соединения к чтению и/или записи. Подход будет использован точно такой же как и в примере отправляющем приветы. А насколько я помню sched — это только запуск калбэка по таймеру.
Насчет очереди событий, да тут собственно и не очередь, а просто добавление в отсортированный список.
Ниже я исправил это упущение :), но там coroutine реализованы без использования возможностей последних новшеств API Enhanced Python Generators, таких как например yield from и возврат значения по return из генератора через свойство value экземпляра класса StopIteration.
Пожалуй наверно стоит добавить, что я не в коей мере не претендую на «открытие coroutine» в Python. статья о том, что последние новшества введенные в язык начиная с версии Python 3.3 делают реализацию сопрограм очень простым и понятным делом. Сама же идея сопрограмм в Pythone основанных на генераторах кажется впервые наиболее полно освещена в этой статье. И я рекомендую её для прочтения, тем кто заинтересовался этой темой, даже не смотря на то что информация там существенно устарела.
Позволю с вами не согласиться, издание от 2010 года, тогда расширенные генераторы Python были разве что в головах тех, кто их потом начал вводить в язык начиная с года 2012. А без наличия этих самых расширенных генераторов, то о чем я писал не имеет смысла вообще. Если же говорить о реализации coroutine, то я упоминал что тема не нова. Интерес и реализации в Python есть уже достаточно давно. Но! Последние изменения в API расширенных генераторов, позволяют сделать реализацию coroutin очень простой и прозрачной.
Попробуйте например без усложнения кода sapmle.py заставить это заработать на Python 2.6, я уже не говорю о том насколько усложниться модуль concurrency. И я в своем примере еще не задействовал возможность возвращения результата из функции sleep, а она есть. На обычных генераторах, без хаков, это в принципе не возможно сделать.
Хотя согласен с тем что книга очень полезная, хотя и малопопулярная почему-то.
Почему вместо? Я думаю ХеллоВорлд она вполне красиво выводит на экран используя всю мощь HTML, CSS, XML, Java и других языков. Но и про порты конечно тоже не забывает.
А фреймворк разве не по определению жестко задает структуру приложения, во всяком случае на низших уровнях?
Дай бог, что бы вы смогли принести новую свежую струю в этот проект, а не помогли похоронить его)
И да, физический возраст «старичка», тут не играет роли.
Вопрос в том, стоит ли заводить вторую БД (MongoDB, etc) для нереляционных фишек? Если бы это давало прирост производительности в разы — то да, если нет — то нет :)
Я думаю очень ожидаема и интересная статья сравнивающая нереляционные фишки PostgreSQL с MongoDB. Во всяком случае это будет действительно интересно для тех, кто сейчас выбирает платформу под проект. А права ли Сара? NBC.
Спасибо сейчас поправлю.
Безусловно, например когда мы будем останавливать выполнение короутины для ожидания готовности сетевого соединения к чтению и/или записи. Подход будет использован точно такой же как и в примере отправляющем приветы. А насколько я помню sched — это только запуск калбэка по таймеру.
Насчет очереди событий, да тут собственно и не очередь, а просто добавление в отсортированный список.
Попробуйте например без усложнения кода sapmle.py заставить это заработать на Python 2.6, я уже не говорю о том насколько усложниться модуль concurrency. И я в своем примере еще не задействовал возможность возвращения результата из функции sleep, а она есть. На обычных генераторах, без хаков, это в принципе не возможно сделать.
Хотя согласен с тем что книга очень полезная, хотя и малопопулярная почему-то.