пятница, 11 января 2013 г.

PandaBoard и Raspberry Pi приписаны к флотилии Buildbot

Благодаря Python Software Foundation, PandaBoard прибыла на стол Трента Нельсона (Trent Nelson) как раз перед праздниками! Санта раздал сегодня утром подарки разработчикам Python и среди них оказался Raspberry Pi.


В недавнем обсуждении Рэймонда Хеттингера (Raymond Hettinger) по поводу распределения памяти в словарях, Берри Варсоу (Barry Warsaw) и Кристиан Хеймес (Christian Heimes) поделились своими мыслями о том, как это может работать на ARM устройствах. Кристиан упомянул про Snakebite, запущенный Трентом Нельсоном, но без самих ARM устройств в этом окружении, и Трент предлогал разместить их, если бы кто-нибудь эти устройства пожертвовал.

На основании этого обсуждения и учитывая низкую стоимость этих устройств, PSF разрешила покупку PandaBoard ES, с 1.2 GHz ARM Cortex A9, и прочим необходимым оборудованием. Несколько Raspberry Pi (с 700 MHz ARMv6) уже были в наличии у PSF, так что одно из них так же было передано Тренту.

Спасибо PSF за это приобретение и спасибо Тренту за настройку машин и добалвение их к своей среде!


суббота, 1 октября 2011 г.

Новый модуль faulthandler - хороший помощник при отладке в Python

Источник: New faulthandler module in Python 3.3 helps debugging

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

Фатальные ошибки

Новый модуль faulthandler, добавленный в Python 3.3, должен помочь в данной ситуации. faulthandler предоставляет возможность дампа бэктрейса стека Python в случае фатальной проблемы наподобие ошибки сегментации, деления на 0, аварийного завершения или ошибки на шине. Включить данную функциональность в своём приложении можно вызовом faulthandler.enable(), при этом указав опцию -X faulthandler при запуске исполняемого файла Python. Ещё один вариант - это установить переменную окружения PYTHONFAULTHANDLER=1. Пример вывода:

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

Таймаут

faulthandler также позволяет дампить бэктрейс по истечению заданного таймаута. Для этого используется вызов faulthandler.dump_tracebacks_later(timeout). Эту же функцию нужно вызовать для того, чтобы перезапустить таймер. Для остановки таймера нужно вызвать функцию faulthandler.cancel_dump_tracebacks_later(). Пример вывода:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

Опция repeat=True используется для дампа бэктрейса каждые timeout секунд, а опция exit=True применяется для немедленного завершения программы небезопасным способом, т.е. без сброса файловых буферов на диск.

Пользовательский сигнал

Если есть доступ на машину, где работает программа, можно использовать механизм faulthandler.register(signal) для установки обработчика сигналов, по которому бдует осуществляться дамп бэктрейса при получении заданного сигнала. В UNIX, например, можно использовать сигнал SIGUSR1: по команде kill -USR1 <pid> будет получен текущий бэктрейс. Эта возможность недоступна на Windows-системах. Пример вывода:

Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

Другая возможность - это явный вызов faulthandler.dump_traceback() в коде программы.

Вопросы безопасности и выходной файл

faulthandler отключён по умолчанию по соображениям безопасности, в основном потому, что он сохраняет файловый дескриптор объекта sys.stderr и пишет бэктрейсы в этот файловый дескриптор. Если sys.stderr закрыт, а дескриптор файла повторно используется, то он может быть сокетом, каналом, критическим файлом или ещё чем-нибудь другим. По умолчанию faulthandler пишет бэктрейсы в sys.stderr, но есть возможность указать другой файл. Более подробную информацию об этом можно получить в документации по faulthandler.

Стороний модуль для старых версий Python

faulthandler также поддерживается как независимый модуль для Python 2.5-3.2 на PyPI. Главное отличие между модулем в Python 3.3 и сторониим модулем - это реализация dump_tracebacks_later(): Python 3.3 использует поток и блокироку с таймаутом, тогда как независимый модуль использует SIGALRM и alarm().

Таймаут блокировки - это новоя возможность в Python 3.3. Он имеет микросекундную точность. alarm() таймер, который используется в старых версиях, обладает точностью в одну секунду, а сигнал SIGALRM может прервать текущий системный вызов, при этом системный вызов завершится с ошибкой EINTR.

Ранний успех

Новый модуль faulthandler уже помог поймать состояние гонки в нашей системе сборке - buildbot. Есть надежда, что он будет полезен также и другим программистам.

Менторская программа для ядра Python

Источник: The Python Core Mentorship Program

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

Разыскиваются контрибьютеры

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

Ранний успех

Программа уже принесла свои плоды и её участники закоммитили некоторое количество патчей. Также было несколько конструктивных дискуссий в списке рассылки, помогающих вести народ в правильном направлении при возникновении различных проблем.

Кодекс поведения

У программы имеется кодекс поведения, который изложен на сайте проекта, предназначенном для смягчения отношений при взаимодействии множества новых контрибьютеров с опытными разработчиками. Также этот кодекс касается списков почтовой рассылки, посвящённых контрибьюции. Джесси и другие менторы надеятся, что эта программа может быть полезна как эталон для других проектов в долгосрочной перспективе, и от её развития будет прок не только ядру Python. Также одной из целей программы является увеличение общей разнородности контрибьютеров Python.

Как принять участие?

Программа запущена через список рассылки, также существует лаконичный и понятный сайт, посвящённый ей. Если читатель хотел бы присоединиться и вступить на путь разработчика ядра Python, то этот проект - великолепная возможность задать вопросы и сделать свои первые шаги в этом направлении. Проект будет полезным и для опытных разработчкиков(уже даже вовлечённых в разработку Python), которые хотели бы задать какие-либо вопросы, но считают их неуместными в других списках рассылки.

среда, 17 августа 2011 г.

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

Источник: Portuguese, German, Korean, and Traditional Chinese Translations

Проект перевода блога Python Insider продолжает развиваться! Мы запускаем португальский, немецкий, корейский и традиционный китайский версии блога. Переводчики уже начали публиковать накопившиеся статьи. Что касается других переводов, они ведутся параллельно с оригинальным блогом Python Insider, но могут незначительно отставать от него.

Перевод блога на румынский и упрощенный китайский языки

Источник: Romanian and Simplified Chinese Translations

Команда Python Insider рада сообщить о запуске блога на двух новых языках. Переводчики на румынский и упрощенный китайский языки присоединились к проекту перевода нашего блога и уже начали публиковать накопившиеся статьи. Что касается других переводов, они ведутся параллельно с оригинальным блогом Python Insider, но могут незначительно отставать от него.

среда, 27 июля 2011 г.

Jython мигрирует на Mercurial

Источник: Jython Migrates to Mercurial

Jython окончательно мигрировал с Subversion на Mercurial. Этого пришлось дожидаться довольно долго: к сожалению, репозиторий на Subversion был сложным, и пришлось приложить некоторые усилия для аккуратного перехода на другую систему контроля версий.

Новый официальный репозиторий Jython сейчас хостится на @

http://hg.python.org/jython

с зеркалом на BitBucket для облегчения форка.

Также существует больший репозиторий, доступный только для чтения, c текущими ветками для разработки новой функциональности (преобразованный в Mercurial Bookmarks). Его можно найти по ссылке http://hg.python.org/jython-fullhistory.

С помощью Mercurial помогать проекту Jython стало даже легче, делаешь форк и вперёд, помогать создавать Jython 2.6!

понедельник, 25 июля 2011 г.

С Python 3.3 заканчивается поддержка OS/2, Windows 2000 и VMS

Источник: Python 3.3 to Drop Support for OS/2, Windows 2000, and VMS

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

Виктор Стиннэ не так давно предложил прекратить поддержку OS/2 и VMS в CPython, через год после его первоначального вопроса касательно поддержки OS/2. Данный вопрос возник у Виктора в то время, когда он работал над поддержкой стандарта Unicode. В основном, проблемы были с os.execvpe() в части поддержки переменных окружения с помощью обработчика surrogateescape, описанного в PEP 383. В данный момент нет команды разработчиков под OS/2 и VMS, поэтому в процессе подготовки релиза не проводится тестирование для этих систем.

Написание данной статьи заставило меня задуматься о предыдущей дискуссии о завершении поддержки Windows 2000, которая, кажется, была заброшена. Тогда же было предложено пустить под нож системы, у которых переменная окружения COMSPEC указывала на command.com. Теперь все эти системы присоединились к более неподдерживаемым OS/2 и VMS. Windows 2000 находится в процессе удаления из списка поддерживаемых систем, что упростит разработку, поскольку пропадает необходимость брать в расчет устаревшие интерфейсы операционных систем, поддержку которых решено было прекратить в 2010 году.

Чтобы запустить процесс завершения поддержки этих систем, мы с Виктором начали с обновления PEP 11.

PEP 11

 

Этот PEP содержит список операционных систем, которые больше не поддерживаются, а также поясняет процедуру добавления системы в этот список.

Как только решено, что для данной операционной системы можно начинать процедуру удаления, она официально объявляется неподдерживаемой. Традиционно такое уведомление включается в ту версию, которая в данный момент находится в разработке. Поэтому поддержка OS/2, Windows 2000 и VMS прекращается в Python версии 3.3.

Первый этап не требует практически никаких усилий, и заключается, в основном, в "поднятии белого флага". Это знак отсутствия кого-либо, кто бы поддерживал код и обеспечивал качественный релиз. Также могут быть сделаны изменения в процессах компиляции и установки для предупреждения пользователей таких платформ о прекращении поддержки. Уведомление будет размещено в документе "What's New", в котором перечислены платформы, поддержка которых прекращается.

После завершения цикла релиза, в котором объявляется об окончании поддержки, в последующей версии можно начать удалять код. В данном случае код может быть удален в версии 3.4. Вероятно, массового удаления такого кода не будет, но разработчики, которые наткнуться на него в процессе своей текущей работы, могут удалять блоки #ifdef, секции в configure или устаревший код.

Что же Вам делать

 

Если Вы являетесь разработчиком под OS/2 или VMS, у Вас есть несколько способов сохранить поддержку для своей платформы.
Стать мейнтейнером
Лучшей поддержкой платформы является активный разработчик. Эндрю МакИнтайр был мейнтейнером OS/2 в течение некоторого времени, и когда Виктор первый раз поднял вопрос про OS/2, Эндрю сообщил, что версия для OS/2 отстает в части поддержки Unicode, а это, безусловно, область, требующая внимания. У VMS есть некоторая внешняя поддержка усилиями разработчиков из http://www.vmspython.org, но, как уже обсуждалось в issue 11918, кто-то должен выступить в роли мейнтейнера.

Если вы заинтересованы участвовать в поддержке той или иной платформы, прочитайте developer's guide для получения информации о текущих процессах разработки.
Подарить компьютер для сборки релизов
С активным разработчиком у платформы есть больший шанс выжить. При наличии компьютера для сборки релиза у платформы есть шанс не только выжить, но еще и повысить качество поддержки.

Python использует Buildbot для непрерывной интеграции, компьютеры для сборки релиза в данный момент доступны для Linux, Mac, Windows и Open Indiana (Solaris), для разных версий, архитектур и конфигураций. Пожертвование машины в парк компьютеров для сборки под OS/2 и VMS позволит релизам для этих ОС получить столько же внимания, сколько уделяется более распространенным платформам.

Если Вы можете пожертвовать своим временем или оборудованием, чтобы помочь сохранить поддержку для OS/2 и VMS, сообщите об этом в список рассылки python-dev.