Читать очень сложно — не надо после почти каждого абзаца вставлять гифки.

Да, нас попросили уйти, потому что один и тот же контент на хабре и в других местах нельзя размещать.

Для перерывов можно использовать Workrave. Раз в определенное время блокирует клавиатуру/мышь.

У меня настроено два перерыва
— каждые 20 минут на 30 секунд
— каждый час на 10 минут

Да, конечно можно.
Обновил пост — добавил видео докладов.
Еще про киви был доклад на 11 встрече, возможно заинтересует — https://habrahabr.ru/post/319658/

Минусуют за рекламу ресурса.

Ушел, потому что правила хабра нарушали — пункт про дублирование информации у себя и на хабре. Поэтому после нескольких банов решили, что хватит нарушать.
andrewnester спрашивал нас, против ли мы или нет — не против. Мощности текущего агрегатора легко предоставим Андрею, как созреет.

Маркетинговая вода. Лучше бы сократили до 3 абзацев эту всю воду.

Исходники в OpenSource выпустите?

Много success stories про использование есть.

Большинство инструментов аналитики, обучения и прочего в Python базируются на numpy, а numpy почти полностью написан на C.
Есть биндинги к системам анализа, который могут работать кластерами — например для Spark — PySpark
Интеграция с GPU тоже есть — через CUDA или NumbaPRO.
Есть куча библиотек для Deep Learning, например, Caffe

Самовар маленький. Там мест сидячих на 20-25 участников. Душно в нем становиться. Поэтому причина — удобство для слушателей.

Но вы можете придти без регистрации. Думаю как-то разместимся.
Только учитывайте, что Самовар — анти-кафе, со всей ценовой политикой подобных заведений.

uwsgi — редкая птица? Или не верно понял?

uwsgi часто используется в стеке с Python.

Использование утилит автоматического форматирования не отменяет написание кода по pep8. Большинство рекомендаций, там описанных, легко соблюдать. Но есть не простые места, на первый взгляд, говорю об отступах. Если вы пишете код в фукциональном стиле, то у вас получается длинная строка, в котором «в кучу кони, люди», (словари, генераторы, листы и тд), а потом начинаете думать, где же ставить здесь переносы, чтобы строка занимала не более 79 символов.

Давно уже заметил, что различные рекомендации по оформлению кода на разных языках программирования, это не скорее не рекомендации, а опыт выработанный кровью. И если 80-90% кода человек может оформить за 20% времени, то остальные моменты пусть доделывает автоматика.

Для справки, у PyCharm по умолчанию весьма глупая проверка на нарушение правил — подсвечивает не все.

Desktop GUI и Web это разные совсем тематики.

Вообще, что для первого, что для второго, стоит ответить на вопросы:

• Нужен ли GUI?
• На самом ли деле нужен ли GUI?
• Для кого делаем GUI?
• Web или Desktop?
• Есть системные ограничения?
• … и вот в таком стиле вопросы все

От этого и станет ясно какие технологии стоит использовать. Может так сложиться, что программой пользуются по принципу «Запустил один раз и весит в фоне — обрабатывает данные», тогда консольного хватит за глаза

В качестве основной IDE для Python использую Pycharm — это для развесистых проектов, для экспериментов (2-3 py-файла) Sublime Text или vim хватает.
GUI почти не разрабатываю, однако, если требуется desktop GUI, то беру PyQt. Потому что, давно писал на Qt/C++ и привычка осталась. Сам интерфейс на 90% руками в коде, на 10% (каркас) делаю с QtDesigner, который потом конвертирую в py файл, а затем редактирую под реальные свои нужны.

вы провели или привели исследования, чтобы выяснить какая реализация языка Python является самой популярной?

Достаточно сказать, что в большинстве Linux'ов стоит именно CPython. А к использованию других реализаций питонов прибегают не так часто и в реальных проектах это скорее исключение, чем правило.

Вы ошибаетесь. Не приходилось разбирать чужой код, написанный в соответствии с этой «рекомендацией»?

Да, получалось вполне успешно читать такие проекты. Если проект больше 10к строк кода, то уже не важно существование pep8 или каких-то других стандартов для языка(если смотрим на на другие языки программирования), то никто не будет переписывать весь продакшн код для удовлетворения каких-то там стандартов. Иначе говоря «работает — не трогай».

Не вижу противоречия, однако, уточню.
Если пишем web-app с javascript, css, шаблонами, то здесь flask, а если только web API к сервису, который живет в вечном loop'e, то зачем тащить flask.
По-моему опыту, в flask удобней сделаны все эти frontend вещи, в bottle они как-то каким-то магическими взмахами делаются. Однако, как раз все в одном файле (для bottle), позволяет его пихать в проекты, где используется чистый python и не беспокоится о версиях библиотек. Во flask такой свободы не ощущается.

Резюмируя, для прототипов, а также не требующих web gui приложений, bottle смотрится более удачным решением, чем flask.
Хотя выбор между микрофреймворками, это как выбор между зеленым и красным, т.е. сути не меняется, сиравно там нет никакой асинхронности.

Из того что видел, flask брали, когда надо уже именно web-приложение, а bottle когда есть питоновская программа (т.е. по сути desktop сервис какой-то), а для нее делали API.