Сначала неизвестно какие версии поддерживают необходимый Python. Обычно при повышении версии пакетов обрезают старые версии Python. Поэтому пока идет ручное обновление и просмотр changelog ставил <=. Тем самым контролировал что не сломается лишнего.
Когда до нужной версии Python поднял, но можно отбросить "старые" версии пакетов и наоборот ставится >=. И обновляются все пакеты. Если что-то сломалось - то индивидуально эти версии меняются на <=
ngrok - классика, когда стоил 5$ было совсем приятно пользоваться и custom domain, и прочим.
Сейчас перешел на localtunnel написанный на nodejs, который без платы дает домен, который не меняется. И не требуется больше ALLOWED_HOSTS обновлять/держать в wildcard режиме.
Да, конечно можно.
Обновил пост — добавил видео докладов.
Еще про киви был доклад на 11 встрече, возможно заинтересует — https://habrahabr.ru/post/319658/
Ушел, потому что правила хабра нарушали — пункт про дублирование информации у себя и на хабре. Поэтому после нескольких банов решили, что хватит нарушать. andrewnester спрашивал нас, против ли мы или нет — не против. Мощности текущего агрегатора легко предоставим Андрею, как созреет.
Большинство инструментов аналитики, обучения и прочего в Python базируются на numpy, а numpy почти полностью написан на C.
Есть биндинги к системам анализа, который могут работать кластерами — например для Spark — PySpark
Интеграция с GPU тоже есть — через CUDA или NumbaPRO.
Есть куча библиотек для Deep Learning, например, Caffe
Самовар маленький. Там мест сидячих на 20-25 участников. Душно в нем становиться. Поэтому причина — удобство для слушателей.
Но вы можете придти без регистрации. Думаю как-то разместимся.
Только учитывайте, что Самовар — анти-кафе, со всей ценовой политикой подобных заведений.
Использование утилит автоматического форматирования не отменяет написание кода по pep8. Большинство рекомендаций, там описанных, легко соблюдать. Но есть не простые места, на первый взгляд, говорю об отступах. Если вы пишете код в фукциональном стиле, то у вас получается длинная строка, в котором «в кучу кони, люди», (словари, генераторы, листы и тд), а потом начинаете думать, где же ставить здесь переносы, чтобы строка занимала не более 79 символов.
Давно уже заметил, что различные рекомендации по оформлению кода на разных языках программирования, это не скорее не рекомендации, а опыт выработанный кровью. И если 80-90% кода человек может оформить за 20% времени, то остальные моменты пусть доделывает автоматика.
Для справки, у PyCharm по умолчанию весьма глупая проверка на нарушение правил — подсвечивает не все.
Вообще, что для первого, что для второго, стоит ответить на вопросы:
Нужен ли 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.
Information
Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity
Specialization
Chief Technology Officer (CTO), Chief information officer (CIO)
Как будто статью забыли оформить, сделайте доп. усилие и оберните код в соответствующий тег с сохранением отступов.
Сначала неизвестно какие версии поддерживают необходимый Python. Обычно при повышении версии пакетов обрезают старые версии Python.
Поэтому пока идет ручное обновление и просмотр changelog ставил <=. Тем самым контролировал что не сломается лишнего.
Когда до нужной версии Python поднял, но можно отбросить "старые" версии пакетов и наоборот ставится >=. И обновляются все пакеты. Если что-то сломалось - то индивидуально эти версии меняются на <=
ngrok - классика, когда стоил 5$ было совсем приятно пользоваться и custom domain, и прочим.
Сейчас перешел на localtunnel написанный на nodejs, который без платы дает домен, который не меняется. И не требуется больше
ALLOWED_HOSTS обновлять/держать в wildcard режиме.Для локальной разработки хватает.
У меня настроено два перерыва
— каждые 20 минут на 30 секунд
— каждый час на 10 минут
Обновил пост — добавил видео докладов.
Еще про киви был доклад на 11 встрече, возможно заинтересует — https://habrahabr.ru/post/319658/
andrewnester спрашивал нас, против ли мы или нет — не против. Мощности текущего агрегатора легко предоставим Андрею, как созреет.
Большинство инструментов аналитики, обучения и прочего в Python базируются на numpy, а numpy почти полностью написан на C.
Есть биндинги к системам анализа, который могут работать кластерами — например для Spark — PySpark
Интеграция с GPU тоже есть — через CUDA или NumbaPRO.
Есть куча библиотек для Deep Learning, например, Caffe
Но вы можете придти без регистрации. Думаю как-то разместимся.
Только учитывайте, что Самовар — анти-кафе, со всей ценовой политикой подобных заведений.
uwsgi часто используется в стеке с Python.
Давно уже заметил, что различные рекомендации по оформлению кода на разных языках программирования, это не скорее не рекомендации, а опыт выработанный кровью. И если 80-90% кода человек может оформить за 20% времени, то остальные моменты пусть доделывает автоматика.
Для справки, у PyCharm по умолчанию весьма глупая проверка на нарушение правил — подсвечивает не все.
Вообще, что для первого, что для второго, стоит ответить на вопросы:
От этого и станет ясно какие технологии стоит использовать. Может так сложиться, что программой пользуются по принципу «Запустил один раз и весит в фоне — обрабатывает данные», тогда консольного хватит за глаза
GUI почти не разрабатываю, однако, если требуется desktop GUI, то беру PyQt. Потому что, давно писал на Qt/C++ и привычка осталась. Сам интерфейс на 90% руками в коде, на 10% (каркас) делаю с QtDesigner, который потом конвертирую в py файл, а затем редактирую под реальные свои нужны.
Достаточно сказать, что в большинстве Linux'ов стоит именно CPython. А к использованию других реализаций питонов прибегают не так часто и в реальных проектах это скорее исключение, чем правило.
Да, получалось вполне успешно читать такие проекты. Если проект больше 10к строк кода, то уже не важно существование pep8 или каких-то других стандартов для языка(если смотрим на на другие языки программирования), то никто не будет переписывать весь продакшн код для удовлетворения каких-то там стандартов. Иначе говоря «работает — не трогай».
Если пишем web-app с javascript, css, шаблонами, то здесь flask, а если только web API к сервису, который живет в вечном loop'e, то зачем тащить flask.
По-моему опыту, в flask удобней сделаны все эти frontend вещи, в bottle они как-то каким-то магическими взмахами делаются. Однако, как раз все в одном файле (для bottle), позволяет его пихать в проекты, где используется чистый python и не беспокоится о версиях библиотек. Во flask такой свободы не ощущается.
Резюмируя, для прототипов, а также не требующих web gui приложений, bottle смотрится более удачным решением, чем flask.
Хотя выбор между микрофреймворками, это как выбор между зеленым и красным, т.е. сути не меняется, сиравно там нет никакой асинхронности.