Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Очень много субъективных предположений, выданных за объективные, например начало и конец:
вы провели или привели исследования, чтобы выяснить какая реализация языка Python является самой популярной?
Вы ошибаетесь. Не приходилось разбирать чужой код, написанный в соответствии с этой «рекомендацией»?
Python, точнее его самый известный представитель CPython
вы провели или привели исследования, чтобы выяснить какая реализация языка Python является самой популярной?
Стоит озвучить вслух следующую рекомендацию при написании кода, которая универсальна для любого языка: более важным правилом оформлением, чем подобные pep8-документы — это постоянство стиля. Выбрали в каком стиле будете писать программу, в этом же и пишите весь код.
Вы ошибаетесь. Не приходилось разбирать чужой код, написанный в соответствии с этой «рекомендацией»?
вы провели или привели исследования, чтобы выяснить какая реализация языка Python является самой популярной?
Достаточно сказать, что в большинстве Linux'ов стоит именно CPython. А к использованию других реализаций питонов прибегают не так часто и в реальных проектах это скорее исключение, чем правило.
Вы ошибаетесь. Не приходилось разбирать чужой код, написанный в соответствии с этой «рекомендацией»?
Да, получалось вполне успешно читать такие проекты. Если проект больше 10к строк кода, то уже не важно существование pep8 или каких-то других стандартов для языка(если смотрим на на другие языки программирования), то никто не будет переписывать весь продакшн код для удовлетворения каких-то там стандартов. Иначе говоря «работает — не трогай».
Спасибо за статью, жду следующую.
Подскажите пожалуйста, какой IDE пользуетесь и как GUI разрабатываете?
PyCharm хорош весьма. Какое именно гуи?
GUI — любое. Desktop GUI или Web.
В кокой-то момент понял что без интерфейса пользователя плохо, а как его быстро и наглядно делать не нашел информации. Разве что Tkinter можно эффективно использовать, поскольку он в комплектность питона входит.
В кокой-то момент понял что без интерфейса пользователя плохо, а как его быстро и наглядно делать не нашел информации. Разве что Tkinter можно эффективно использовать, поскольку он в комплектность питона входит.
Desktop GUI и Web это разные совсем тематики.
Вообще, что для первого, что для второго, стоит ответить на вопросы:
От этого и станет ясно какие технологии стоит использовать. Может так сложиться, что программой пользуются по принципу «Запустил один раз и весит в фоне — обрабатывает данные», тогда консольного хватит за глаза
Вообще, что для первого, что для второго, стоит ответить на вопросы:
- Нужен ли GUI?
- На самом ли деле нужен ли GUI?
- Для кого делаем GUI?
- Web или Desktop?
- Есть системные ограничения?
- … и вот в таком стиле вопросы все
От этого и станет ясно какие технологии стоит использовать. Может так сложиться, что программой пользуются по принципу «Запустил один раз и весит в фоне — обрабатывает данные», тогда консольного хватит за глаза
Меня не интересуют подробности технологий, описание разницы реализаций, тонкости построения хорошего интерфейса. Я спрашиваю
Вот вы GUI разрабатываете на Python для своих проектов??? Если да — опишите как (насколько полно это описывать — решайте сами). Мне будет достаточно ответа в духе «Tkinter» или «PyQt». Если вы ещё добавите описание вида «без дизайнера форм» — будет совсем хорошо.
как GUI разрабатываете?
Вот вы GUI разрабатываете на Python для своих проектов??? Если да — опишите как (насколько полно это описывать — решайте сами). Мне будет достаточно ответа в духе «Tkinter» или «PyQt». Если вы ещё добавите описание вида «без дизайнера форм» — будет совсем хорошо.
Ой, прошу прощения. Не понял что комментарий чуть ниже как раз Вам и принадлежит.
В качестве основной IDE для Python использую Pycharm — это для развесистых проектов, для экспериментов (2-3 py-файла) Sublime Text или vim хватает.
GUI почти не разрабатываю, однако, если требуется desktop GUI, то беру PyQt. Потому что, давно писал на Qt/C++ и привычка осталась. Сам интерфейс на 90% руками в коде, на 10% (каркас) делаю с QtDesigner, который потом конвертирую в py файл, а затем редактирую под реальные свои нужны.
GUI почти не разрабатываю, однако, если требуется desktop GUI, то беру PyQt. Потому что, давно писал на Qt/C++ и привычка осталась. Сам интерфейс на 90% руками в коде, на 10% (каркас) делаю с QtDesigner, который потом конвертирую в py файл, а затем редактирую под реальные свои нужны.
Для винды есть IronPython, но без дизайнера форм.
IDE – vim (как и для всего остального, впрочем). GUI – Qt. Без дизайнера форм отлично всё описывается в инициализаторах классов.
Python, точнее его самый известный представитель CPython, не очень предназначен для каких-либо быстрых расчетов.
Если решать задачи в лоб (с вложенными или просто огромными циклами, например), получается действительно довольно медленно. Если же пользоваться итераторами, корутинами, стандартными библиотеками itertools, functools или внешней scipy, выходит вполне приемлемая производительность, которой для большинства случаев хватает. Не зря же довольно много ученых выбирают python для своих исследований.
Плюс ко всему в CPython отлично реализована поддержка больших чисел (тип long), работает просто молниеносно.
numpy (лежит в основе scipy) работает более-менее быстро потому, что там довольно много кода реально на фортране…
Откуда вы про фортран то взяли? C — 53.7%, Python — 45.4%, Others — 0.9%. Цифры из главного репозитория на github.
gfortran он просто так для сборки тащит?
To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN 77 compiler installed.docs.scipy.org/doc/numpy/user/install.html
C таким же успехом можно о любой программе сказать, что в ней много кода на C — почти всё слинковано с glibc.
Когда критичный по скорости исполнения код написан на C или Fortran, как в случае матричных вычислений в numpy, вполне корректно говорить, что скорость работы определяется в том числе наличием этого нативного кода.
Некоторые, конечно, собирают его без blas/atlas, но это какая-то перверсия, когда вычисления занимают хотя бы десятки минут.
Если внимательно прочитать мой оригинальный комментарий, то можно узреть, что я лишь утверждал, что нормальная скорость работы numpy определяется тем, что критичные операции реализованы в нативном коде на фортране. В этом нет ничего плохого.
Некоторые, конечно, собирают его без blas/atlas, но это какая-то перверсия, когда вычисления занимают хотя бы десятки минут.
Если внимательно прочитать мой оригинальный комментарий, то можно узреть, что я лишь утверждал, что нормальная скорость работы numpy определяется тем, что критичные операции реализованы в нативном коде на фортране. В этом нет ничего плохого.
Да. Но это библиотеки, никак не относящиеся к NumPy. Это отдельные проекты, которые используются в куче другого научного софта. И говорить, что в NumPy «довольно много кода реально на фортране» не корректно. Это лишь использование сторонних нативных библиотек.
Угу, недаром numpy core использует функции из cblas… Так что эти «никак не относящиеся» библиотеки реализуют ядро функционала numpy.
Я ваш тезис понял и согласен, что форма высказывания была неаккуратная.
Имелось ввиду то, что скорость работы scipy/numpy определяется тем, что numpy использует нативную реализацию критичных вычислений.
Если посмотреть выше, то я отвечал на следующее утверждение:
Я ваш тезис понял и согласен, что форма высказывания была неаккуратная.
Имелось ввиду то, что скорость работы scipy/numpy определяется тем, что numpy использует нативную реализацию критичных вычислений.
Если посмотреть выше, то я отвечал на следующее утверждение:
Если же пользоваться… scipy, выходит вполне приемлемая производительность, которой для большинства случаев хватает. Не зря же довольно много ученых выбирают python для своих исследований.
Ну так и сам CPython не на python написан:)
О, спасибо. А то меня совсем достало постоянно потом ходить по файлу и исправлять пробелы после запятых и прочую ерунду.
Для Sublime есть плагин Python PEP8 Autoformat
Нажимем ctrl+shift+r и код форматируется.
А еще есть pytest-pep8
Нажимем ctrl+shift+r и код форматируется.
А еще есть pytest-pep8
Для Sublime еще есть AutoPEP8: умеет форматировать файлы в директории, а также показывать превью форматирования.
Для Sublime есть github.com/DamnWidget/anaconda На мой взгляд лучший плагин, но только для Sublime 3, но она пока dev и бесплатна также, и ключи со второй подходят.
А однажды прочитать PEP8 и впредь стараться соответствовать ему, что мешает? Тот же Pycharm всегда подскажет, если вдруг допустили ошибку случайно (иногда я нарушаю PEP8 специально, да, и не IDE меня судить).
Я готов понять использование утилит для автоматического причесывания кода в случаях, когда под руку попался затронутый в комментариях проект на 10 килострок кода, и глаза б ваши не видели этот ад.
Я также готов понять подобные инструменты, например, для CSS. Когда вы писали стили, писали, а в итоге надо привести все к единообразию, упорядочить свойства по алфавиту, например, и все такое.
Но если вы сами пишете код на пайтоне, почему бы сразу не форматировать нормально? Используя средства автоматического форматирования вы усложняете себе задачу последующего чтения своего же кода. Это не тот код, который вы писали.
Я готов понять использование утилит для автоматического причесывания кода в случаях, когда под руку попался затронутый в комментариях проект на 10 килострок кода, и глаза б ваши не видели этот ад.
Я также готов понять подобные инструменты, например, для CSS. Когда вы писали стили, писали, а в итоге надо привести все к единообразию, упорядочить свойства по алфавиту, например, и все такое.
Но если вы сами пишете код на пайтоне, почему бы сразу не форматировать нормально? Используя средства автоматического форматирования вы усложняете себе задачу последующего чтения своего же кода. Это не тот код, который вы писали.
А зачем задумываться о том, о чем может думать машина? Читать автоформатирование не мешает — это надо совсем треш писать, чтобы все поменялось до степени нечитания. А вот помарки и прочее исправляются автоформатером
Использование утилит автоматического форматирования не отменяет написание кода по pep8. Большинство рекомендаций, там описанных, легко соблюдать. Но есть не простые места, на первый взгляд, говорю об отступах. Если вы пишете код в фукциональном стиле, то у вас получается длинная строка, в котором «в кучу кони, люди», (словари, генераторы, листы и тд), а потом начинаете думать, где же ставить здесь переносы, чтобы строка занимала не более 79 символов.
Давно уже заметил, что различные рекомендации по оформлению кода на разных языках программирования, это не скорее не рекомендации, а опыт выработанный кровью. И если 80-90% кода человек может оформить за 20% времени, то остальные моменты пусть доделывает автоматика.
Для справки, у PyCharm по умолчанию весьма глупая проверка на нарушение правил — подсвечивает не все.
Давно уже заметил, что различные рекомендации по оформлению кода на разных языках программирования, это не скорее не рекомендации, а опыт выработанный кровью. И если 80-90% кода человек может оформить за 20% времени, то остальные моменты пусть доделывает автоматика.
Для справки, у PyCharm по умолчанию весьма глупая проверка на нарушение правил — подсвечивает не все.
Кстати, если кто пользуется вимом могу посоветовать отличное расширение github.com/hynek/vim-python-pep8-indent
В статье забыли указать про полезный github.com/timothycrosley/isort
И кстати кто-нибудь подключал в pycharm внешний автоформаттер типа pyformat, autoflake, autopep8? Я знаю там встроен свой автоформаттер, но я не нашел как его настроить, добавить исключения. Как подключить isort я совсем не разобрался, неужели там нет возможности цеплять хуки на событие post save для файла?
isort your python imports for you so you don't have to.
isort is a Python utility / library to sort imports alphabetically, and automatically separated into sections. It provides a command line utility, Python library and plugins for various editors to quickly sort all your imports. It currently cleanly supports Python 2.6 — 3.4 using pies (https://github.com/timothycrosley/pies) to achieve this without ugly hacks and/or py2to3.
И кстати кто-нибудь подключал в pycharm внешний автоформаттер типа pyformat, autoflake, autopep8? Я знаю там встроен свой автоформаттер, но я не нашел как его настроить, добавить исключения. Как подключить isort я совсем не разобрался, неужели там нет возможности цеплять хуки на событие post save для файла?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Форматирование Python-кода