Python *

Примечание от переводчика:
Представляю вам, перевод интересной статьи Армина Ронахера, автора веб-фреймворков Flask и Werkzeug, шаблонизатора Jinja2 и вообще известного питониста об актуальных техниках и подводных камнях, применяемых им в его проектах при добавлении поддержки третьего питона. Небольшая заметка по поводу названия данной статьи. Оно является отсылкой к статье Армина 2010 года «Портирование на питон 3. Руководство», в которой он описывал подготовку кода для автоматического портирования через утилиту 2to3. Как показывает практика, сегодня такой подход является скорее антипаттерном, т.к. с одной стороны, качество кода в результате подобных операций заметно ухудшается, а кроме того, такой код заметно труднее поддерживать.

После чрезвычайно болезненного опыта портирования Jinja2 на третий питон, мне пришлось оставить проект на холостом ходу на некоторое время, т.к. я слишком сильно боялся сломать поддержку питона 3 версии. Подход, который я использовал состоял в написании кода для питона 2 версии и перевода с помощью 2to3 на третий питон во время установки пакета. Самым неприятным побочным эффектом стало то, что любое изменение, которое вы вносите, требует примерно минуты на перевод, тем самым убивая скорость ваших итераций. К счастью, оказалось, что если правильно указать конечные версии питона, процесс идет ощутимо быстрее.

Томас Волдман из проекта MoinMoin начал с запуска Jinja2 через мой python-modernize с правильными параметрами, и пришел к единому коду, который работает под 2.6, 2.7 и 3.3. Путем небольших приборок мы смогли прийти к приятной кодовой базе, которая работает со всеми версиями питона и при этом, в большинстве своем, выглядит, как обычный код на питоне.

Вдохновившись этим результатом, я несколько раз прошерстил код и начал переводить кое-какой другой код, чтобы дополнительно поэкспериментировать с объединенной кодовой базой.

В данной статье я выборочно рассмотрю некоторые советы и фишки, которыми я могу поделиться, на случай если они кому-либо помогут в схожих ситуациях.

Отлаживая разные алгоритмы управления для нашего робота, мы на себе прочувствовали насколько приятно было бы иметь среду моделирования и отлаживать программы сначала в ней, а потом уже тестировать на реальном роботе. Поскольку мы активно использовали Blender для создания моделей для 3Д-печати и для пользовательского интерфейса, мы решили попробовать Blender Game Engine в качестве среды для моделирования робота. Первые результаты оказались очень даже неплохими:

Эта статья написана Павлом Минаевым int19h — разработчиком из команды PTVS специально для публикации в нашем корпоративном блоге на Хабрахабре. Делитесь вашими впечатлениями в комментариях. Все отзывы будут переданы команде.

Здравствуйте! Я – разработчик из команды Python Tools for Visual Studio. На днях мы выпустили новую бета-версию нашего продукта, и, воспользовавшись поводом, в этот раз я хотел бы поподробнее рассказать о том, что из себя представляет PTVS, и что он может вам предложить.

Одним из главных преимуществ фреймворков является их предопределённая архитектура. Открываешь незнакомый проект и сразу знаешь, где и как искать код связи с БД, или HTML, или схему url. Кроме того, она позволяет разработчику не задумываться над структурой хранения кода и при этом быть уверенным, что проект будет выглядеть более менее адекватно. Но хочу рассказать о случае, когда реализация MVC в Django, а именно распределение логики по файлам models, forms, views, templates оказалась неудобной и какую на её основе построили альтернативу.

Встала у нас задача сделать движок для статистической отчетности на Django. Мы создали селекторы для получения данных из Oracle и виджеты для отображения этих данных в виде таблиц или графиков (с помощью HighChart). Но это всё чисто технологические решения, без особой магии. Если появятся интересующиеся, расскажу в отдельном посте. А сейчас хотелось бы обратить внимание на более необычную часть проекта. На предоставление составителям отчетов удобного способа эти отчеты составлять.

Введение

Как-то возникла необходимость быстро восстановить ход решения одной задачи. Т.е. у меня был набор входных данных и полученные результаты. Хотелось быстро найти алгоритмы, по которому были получены все ответы. Я попытался написать программу-подсказчик.

Привет, Хабр!

В статье я опишу свой небольшой open-source проект — Centrifuge (далее Центрифуга). Это сервер на Python, задача которого — рассылка (broadcast) сообщений в реальном времени подключенным (в основном из браузера) клиентам.

Это будет история, наполненная как личными эмоциями, так и описанием используемых технологий, но без примеров кода. Если вам близка тема — не проходите мимо, будет любопытно.

Для начала, посмотрите, пожалуйста, скринкаст (не забудьте включить субтитры), если после просмотра интерес не пропадет, смело читайте дальше!

В проекте, над которым я работаю, мы используем огромное количество сторонних библиотек. Многие из них — адаптеры для различных сервисов. Что их объединяет, это то, что они работают с сетью. Json поверх http, soap поверх http, какие-то свои протоколы поверх http. Т.е. все так или иначе используют http. И как ни удивительно, мало кто из них пользуется преимуществами его последней версии. Я не поленился заглянуть в википедию, прошло ровно 14 лет как была принята спецификация http 1.1. И потому я решил обратиться с призывом:


Да, речь пойдет о keep alive. Суть в том, что, начиная с http 1.1, клиент и сервер могут договориться не закрывать установленное tcp-соединение после завершения запроса, а переиспользовать его для следующих запросов. Это нужно потому, что на установку соединения требуется время. Иногда это время больше, чем время самого запроса. И если все серверы уже давным-давно такую возможность поддерживают, а все браузеры и большинство других клиентов её используют, то у разработчиков различных библиотек для популярных языков программирования здесь почему-то пробел.

Я уже давно заметил, что данные в социальных сетях хранятся плохо. Например, сделанный вами репост окажется пустым, если автор оригинальной записи ее удалит. Недавние проблемы с аудиозаписями в vk стали последней каплей, и я решил сохранить локально все данные, которые могут представлять интерес на случай ядерной войны. Поискав готовые решения, я не нашел ничего, что бы устроило меня, поэтому за несколько дней был написан скрипт на Python.

Доброго времени суток, Хабрахабр. Сегодня на крыле принес еще один перевод я (pdf-ки гугловского стайл гайда выложены). Хотя, кто знает, если кто-то оценит сию работу — быть может появится и продолжение. Как-то днём одним, предложил мне мой широко известный в узких кругах коллега scraplesh почитать ресурс — The Hitchhiker’s Guide to Python! называемый. Ресурс этот понравился мне. Понравились советы выдаваемые там. Понравилась канва повествования и вообще понравилось направление мысли автора. А если что-то хорошо на Ваш вкус, то нужно передавать это из уст в уста:) Итак, решил я сделать перевод данного ресурса. Но не всё так сразу — сначала будет пробная статья «на отклик» хабрасообщества. Если уважаемым гикам понравится сия тематика и изложение — будем стараться выпускать новые части. На первый «отклик» я выбрал раздел — "Writing Great Code" и в нем два подпункта «Structure is Key» и «Modules». Откликнемся под катом.

Во времена, когда я писал на Лиспе и совсем не был знаком с ООП, я пытался найти паттерны проектирования, которые мог бы применить у себя в коде. И всё время натыкался на какие-то жуткие схемы классов. В итоге сделал вывод, что эти паттерны в функциональном программировании не применимы.

Теперь я пишу на Питоне и с ООП знаком. И паттерны мне теперь намного понятней. Но меня по-прежнему воротит от развесистых схем классов. Многие паттерны прекрасно работают в функциональной парадигме. Опишу несколько примеров.

Хочу представить сообществу своё небольшое творение — Chatter.

Chatter основан на python 2.7, использует tornado.

Имеется готовое API для python (бэкэнд) и для js (фронтэнд)

Примеры и исходный код на github.

Для чего же собственно он был создан?

В техническом блоге «Спотифая» было опубликовано интересное исследование на тему взлома аккаунтов сервиса путём использования особенностей канонизации вводимых пользователем данных. Это стало возможным благодаря тому, чем спотифаевцы гордятся, — полностью юникодному логину. К примеру, пользователь легко может иметь снеговика в качестве имени аккаунта, если он того пожелает. Реализация подобного, впрочем, с самого начала доставляла некоторые неудобства.

Несколько лет назад в Великую пятницу на форуме техподдержки было опубликовано сообщение о возможности взлома любого аккаунта на сервисе. Представитель компании попросил продемонстрировать это на примере его собственного аккаунта, и через несколько минут ему был задан новый пароль и создан новый плейлист. Это немедленно привлекло внимание нескольких сотрудников, вынужденных провести Пасху в попытках закрыть «дыру». В связи с особенностями уязвимости регистрация новых аккаунтов была временно закрыта.

Хакер действовал следующим образом: желая взломать аккаунт с именем, скажем, bigbird, он регистрировал аккаунт с именем ᴮᴵᴳᴮᴵᴿᴰ (в Пайтоне эта строчка выглядит как u’\u1d2e\u1d35\u1d33\u1d2e\u1d35\u1d3f\u1d30′). После запроса ссылки на сброс пароля задавался новый пароль, который подходил к аккаунту bigbird.

Внимание! Статья не претендует на научное соискательство. Опубликована исключительно в целях помочь тем, кто не хочет писать код сам. Если Вы не слушаете музыку вконтакте, не пользуетесь соц. сетями и у Вас аллергия на мой говнокод код написанный студентом, Вам будет не интересно.

Примерно год назад я написал скрипт для скачивания музыки из vk, причем в нормальном качестве (хотя бы > 250 кбит/c ). Он будет полезен для тех, кто хочет скачать свой плейлист вконтакте или просто для удобного выкачивания музыки пока не поздно. Под «удобным скачиванием», на тот момент, я понимал скачивание песен являющимися саундтреками к какому-либо сериалу или фильму, скачивание по артисту и скачивание по названию. Например вводим «OST Pulp Fiction» и получаем папку с песнями из кинофильма Криминальное чтиво.

Когда не стало Kodos

Беда пришла неожиданно. Из Debian Wheezy изъяли старый, добрый PyQt3. А с ним на покой отправился и Kodos — мой любимый дебаггер регулярных выражений Питона. Много лет он помогал тестировать красивые и жуткие конструкци и тот факт, что apt-get install kodos больше не работает, вызвал желание немедленно исправить это досадное недоразумение.

Disclaimer: я начал писать этот скрипт, когда весёлые новости ещё не подоспели.

Буду краток.

• Что оно делает?
  
  • Переупорядочивает треки в вашем плейлисте в VK так, чтобы с минимальным вмешательством он стал выглядеть аккуратнее.
• Где взять?
  
  • На гитхабе. Download now.
• Как пользоваться?
  
  • Понадобится Python 2.7.x. Качаете, устанавливаете. Берёте файл vk_music_organizer.py из архива, открываете в блокноте, в самом начале пишете в строках email = '...' и password = '...' свой логин и пароль соответственно. Сохраняете. Если у вас корректно установлен Python, то после этого достаточно просто запустить этот файл двойным щелчком.

Армин Ронахер опубликовал в своем блоге новость об обновлении популярных веб-фреймоворков для питона: Flask и лежащего в его основе Werkzeug. Самым главным изменением стала поддержка питона 3 версии (начиная с 3.3 и выше). Также низкоуровнеый API Werkzeug был несколько изменен, чтобы с одной стороны реализовать поддержку спецификации из PEP 3333, а с другой — не потерять в производительности. С новой версией теряется поддержка питона версии 2.5.

Если вы используете Werkzeug, то, с обновленной версией, возможно, придется повозиться. Что касается Flask — то тут все несколько проще, т.к. API не сильно изменился.

Важно заметить, что Flask и Werkzeug в определенном смысле несколько затянули обновлением, ведь наиболее популярные компоненты, составляющие стандартный стек фласк-приложения: шаблонный движок Jinja2 и ORM SQLAlchemy уже достаточно продолжительное время поддерживают питон третьей версии. К слову, в свое время, Армин критиковал у себя в блоге слишком радикальные изменения языка, и довольно холодно отзывался о третьей версии.

Многим уже надоело лазить по куче сайтов и скачивать js библиотеки и плагины. Да и таскать когда-то скачанные, но уже давно протухшие версии не очень круто. Эти проблемы решает bower.

Но с ним тоже многое нужно делать вручную: следить за components каждого проекта, руками дёргать bower install. После pip с requirements.txt это делать даже как-то лень.

Поэтому представляю вам django-bower, который берёт на себя установку и обновление bower пакетов по списку из settings и прозрачную работу с staticfiles.

Приглашаем всех разработчиков на Python принять участие в DevConf::Python
14 июня в Москве.
Приезжает автор книги «Porting to Python 3» Lennart Regebro
Секция организована Moscow Django Meetup при активной поддержке Python.su

Первым трем — приславшим в оргкомитет свое фото с галстуком «Python» —
бесплатное участие в основном дне конференции!
(Акция проводится с 9 по 13 июня. Фотошоп не принимается)

Питонисты всех стран, соединяйтесь!

Для одного общественного проекта (визуализация бюджетов поселений и районов) мне потребовались данные об иерархии муниципальных образований и их численности.
Нужные данные я нашел, но форма их представления для корректного использования оставляла желать лучшего.
Все необходимые данные были в одном файле, однако, его форматирование затрудняло извлечение иерархии.

В ходе одного из моих питоновских проектов, с большой примесью ООП и обработкой большого числа данных — у меня возник вопрос, а насколько эффективно обрабатывать списки в классе с использованием вызовов его методов, или может использовать вызов внешней функции? Для этого были написаны 24 теста которые показали очень интересные результаты, Кому интересна данная тема, прошу в подробности.