Python *

Как часто вам присылают подобные отчеты об ошибке?

Traceback (most recent call last):
...
  File "...", line ..., in ...
    process(lst[index])
IndexError: list index out of range

Ох, если бы только узнать значение lst и index на тот момент...

python-catcher — автоматическая генерация HTML-трейсбеков с локальными переменными и исходниками, + загрузка в интернет — пользуйтесь на здоровье.

Прочитал статью «Эстафета из 50-ти квайнов». Действительно, человек написал потрясающую штуку, колоссальный труд, настоящее произведение искусства. Но по комментам судя, многие не понимают, как подобные вещи делаются и полагают их чем-то на грани, если не за гранью, человеческих возможностей, особенно много эмоций было по поводу эзотерических языков (Brainfuck, Unlambda, Whitespace) в списке.
В этой статье я попытаюсь объяснить, как подобные квайны пишутся.

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

Вот почему я делюсь с вами библиотекой python-reconfigure.

В прошлом году на Хабре уже была очень развёрнутая статья в двух частях о декораторах. Цель этой новой статьи — cut to the chase и сразу заняться интересными, осмысленными примерами, чтобы успеть затем разобраться в примерах ещё более мудрёных, чем в предыдущих статьях.
Целевая аудитория — программисты, уже знакомые (например по C#) с функциями высшего порядка и с замыканиями, но привыкшие, что аннотации у функций — это «метаинформация», проявляющаяся только при рефлексии. Особенность Питона, сразу же бросающаяся в глаза таким программистам — то, что присутствие декоратора перед объявлением функции позволяет изменить поведение этой функции:



Как это работает?

Nitrous.IO — это online IDE для веб разработки на Ruby, Python, Node.js и Go (авторы общеют больше вариантов со временем). Главными отличиями от десятка подобных проектов являются полноценный SSH-доступ к своим боксам (о них чуть ниже) и десктоп приложение, синхронизирущее локальный код с боксами, также как это делает Dropbox. И главное — в базовом варианте все это предоставляется бесплатно, поэтому попробовать и понять, нужно ли оно вам — крайне просто.

Всем любителям Python и Яндекс.Метрики доброго дня!

Некоторые знают, что с некоторых пор я заделался Web-разработчиком, впрочем это громко сказано. Мой сайт с занимательными задачками, кстати, если кому интересно, попасть туда можно вот по этой ссылке, медленно, но верно, катится в топы поисковиков, благо альтернатив не так много. О посещаемости на сайте я узнаю из отчетов уже полюбившейся мне яндекс.метрики. В принципе, там есть большинство из того, что мне нужно. Но каждый раз ходить на из сайт для того, чтобы посмотреть количество визитеров как-то не фонтан. И вот тут я снова, как нельзя кстати, вспомнил, что в общем-то я программист и учу питон. «Ладно», — подумал я — «заодно и в работе с сетью попрактикуюсь». Сказано-сделано. Через протокол oAuth регистрируем приложение и получаем для него отладочный токен (живет он бессрочно и каждый раз запрашивать его не надо. Так что под наши нужды — самое то!). Для всех интересующихся, под катом привожу код библиотеки, которую можно привязать к любому GUI — интерфейсу:

Не буду долго распинаться на тему того, насколько велик и могуч Vim — это уже давно и достоверно известно. Кто-то даже утверждает, что «Практически любая строка латинских букв является синтаксически верной командой для vi».

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

Это перевод 1.17 версии руководства от Rafe Kettler.

Содержание

1. Вступление
2. Конструирование и инициализация
3. Переопределение операторов на произвольных классах
   • Магические методы сравнения
   • Числовые магический методы
4. Представление своих классов
5. Контроль доступа к атрибутам
6. Создание произвольных последовательностей
7. Отражение
8. Вызываемые объекты
9. Менеджеры контекста
10. Абстрактные базовые классы
11. Построение дескрипторов
12. Копирование
13. Использование модуля pickle на своих объектах
14. Заключение
15. Приложение 1: Как вызывать магические методы
16. Приложение 2: Изменения в Питоне 3

Вступление

Что такое магические методы? Они всё в объектно-ориентированном Питоне. Это специальные методы, с помощью которых вы можете добавить в ваши классы «магию». Они всегда обрамлены двумя нижними подчеркиваниями (например, __init__ или __lt__). Ещё, они не так хорошо документированны, как хотелось бы. Все магические методы описаны в документации, но весьма беспорядочно и почти безо всякой организации. Поэтому, чтобы исправить то, что я воспринимаю как недостаток документации Питона, я собираюсь предоставить больше информации о магических методах, написанной на понятном языке и обильно снабжённой примерами. Надеюсь, это руководство вам понравится. Используйте его как обучающий материал, памятку или полное описание. Я просто постарался как можно понятнее описать магические методы.

По работе мне часто приходится вести переписку на английском, и в силу недолеченного перфекционизма, пользоваться для этого оффлайн/онлайн переводными/толковыми словарями. В целом они со своей работой справляются, пока дело не доходит до проверки правильности словосочетаний или целых фраз. Хочешь ввернуть что-нибудь из разряда продвинутого владения языком, но нет уверенности, что правильно помнишь (большой привет предлогам и фразовым глаголам).

Есть парочка ресурсов, для поиска фраз, но заточены они в основном под общеупотребимые словосочетания, пословицы и фразеологизмы на отдельно взятом языке. К тому же не известно пользуются ли люди искомой фразой или употребив её вы поставите в тупик даже носителя языка.

Примечание от переводчика:
Представляю вам, перевод интересной статьи Армина Ронахера, автора веб-фреймворков 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.

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