Предыстория

Присоединяюсь к MaxElc, DarwinTenk и Devgru :) Начинаю цикл статей посвященных Python. Сам я имею некоторый опыт обращения с PHP и Java. Но каждый раз, при относительном освоении какого-то инструмента — оставалось определённое неудовлетворение им, связанное с чем-то конкретным, и поиски продолжались. На сегодняшний день наиболее близко к идеалу в моих глазах стоит Python. Идеал недостижим — это понятно, посему и у Python есть недостатки. Прежде всего — это скорость выполнения, однако, эта проблема решаема несколькими путями и об этом мы обязательно поговорим чуть позднее.
Сам я начал осваивать Python буквально недавно. Начиная этот цикл статей — я преследую несколько целей. Во-первых, это дополнительная само мотивация + интерактивность, во-вторых, опыт. В-третьих, блуждая по просторам рунета — вижу, что Python куда менее популярен, чем в мире. Ситуацию надо исправлять :)
В соответствии с идеологией Python, а именно с тем, что одни из главных его козырей — это быстрота в освоении и скорость разработки, мы достаточно быстро, практически тезисно пронесёмся по основам синтаксиса и построения программ и перейдём к основной цели данного цикла — освоение django.
Итак, мы начинаем.

PyPy теперь умеет загружать и запускать расширения CPython'а (то есть, .pyd и .so файлы) напрямую, при помощи новой подсистемы, которая называется CPyExt. В отличие от решения, представленного в другом блог-посте (в котором модули расширения типа numpy запускались на CPython и проксировались через TCP), новое решение больше не требует запущенного CPython. Мы пока ещё не достигли полной бинарной совместимости (как Ironclad), но, в большинстве случаев, достаточно просто перекомпилировать расширение.

Единственное требование — необходимые функции C API из CPython должны быть реализованы в PyPy. Если вы пользователь или автор модуля, и вам не хватает некоторых функций в PyPy, мы приглашаем вас их реализовать. Уже довольно много людей (включая много новых контрибьюторов) уже включились в разработку и реализовали некоторые функции для того, чтоб их любимые модули заработали. В конце поста — список имён.

Кстати о скорости. Несмотря на то, что существуют накладные расходы на запуск этих модулей, когда мы запускаем движок регулярных выражений из CPython (_sre.so) и проходим бенчмарк spambayes из набора бенчмарков Unladen Swallow (см speed.pypy.org), то получаем значительное ускорение: тест стал вдвое быстрее по сравнению с движком регулярок, встроенным в PyPy. Из закона Амдала следует, что _sre.so должен работать в несколько раз быстрее, чем встроенный движок.

В данный момент идёт работа над PIL и другими модулями. Например, поддержка distutils уже почти завершена. И если вы хотите участвовать в этом или получить больше информации о том, как использовать эту новую возможность, заходите на наш IRC-канал #pypy на freenode.

Вслед за обновлением IronRuby, обновилась и реализация языка Python для .NET – IronPython. В новой версии IronPython 2.7 Alpha добавлена предварительная поддержка CPython 2.7 и проведены другие изменения:

• добавлена интеграция с Visual Studio (набор IronPython Tools for Visual Studio);
• расширена документация по CPython 2.7 с полезной информацией относящейся к IronPython;
• добавлены модули mmap и signal;
• произведено некоторое количество улучшений производительности и исправлений ошибок;
• лицензия изменена с MSPL на Apache License, Version 2.0;
• новая версия требует .NET 4.0 и Silverlight 4.0.

Загрузить пакет установки новой версии IronPython 2.7 можно по этой ссылке.

Посетите официальный сайт проекта по адресу http://www.ironpython.net/.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

Помимо изучения стандартной библиотеки, всегда интересно, а иногда и полезно, знать, как язык устроен изнутри. Андрей Светлов (svetlov), один из разработчиков Python, советует всем интересующимся серию статей об устройстве CPython. Представляю вам перевод первого эпизода.

Мой друг однажды сказал мне: «Знаешь, для некоторых людей язык C — это просто набор макросов, который разворачивается в ассемблерные инструкции». Это было давно (для всезнаек: да, ещё до появления LLVM), но эти слова хорошо мне запомнились. Может быть, когда Керниган и Ритчи смотрят на C-программу, они на самом деле видят ассемблерный код? А Тим Бёрнерс-Ли? Может он сёрфит интернет по-другому, не так, как мы? И что, в конце концов, Киану Ривз видел в том жутком зелёном месиве? Нет, правда, что, чёрт побери, он там видел?! Эм… вернёмся к программам. Что видит Гвидо ван Россум, когда читает программы на Python?

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

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

Как я и писал в предыдущем эпизоде (который, кстати, оказался успешным; спасибо всем, ваши просмотры и комментарии буквально заставляют меня двигаться дальше!) – сегодняшний пост посвящён реализации объектов в Python 3.x. Поначалу я думал, что это простая тема. Но даже когда я прочитал весь код, который нужно было прочитать перед тем, как написать пост, я с трудом могу сказать, что объектная система Питона… гхм, «простая» (и точно не могу сказать, что до конца разобрался в ней). Но я ещё больше убедился, что реализация объектов — хорошая тема для начала. В следующих постах мы увидим, насколько она важна. В то же время, я подозреваю, мало кто, даже среди ветеранов Питона, в полной мере в ней разбирается. Объекты слабо связаны со всем остальным Питоном (при написании поста я мало заглядывал в ./Python и больше изучал ./Objects и ./Include). Мне показалось проще рассматривать реализацию объектов так, будто она вообще не связана со всем остальным. Так, будто это универсальный API на языке C для создания объектных подсистем. Возможно, вам тоже будет проще мыслить таким образом: запомните, всё это всего лишь набор структур и функций для управления этими структурами.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

В предыдущей части мы начали изучение объектной системы Питона: поняли, что именно можно считать объектом и каким образом объекты выполняют свою работу. Продолжим рассмотрение вопроса.

Приветствую вас в третьей части нашего цикла статей о внутренностях Питона (строго рекомендую прочитать вторую часть, если вы этого ещё не сделали, иначе ничего не поймёте). В этом эпизоде мы поговорим о важном понятии, к которому всё никак не подберёмся, — об атрибутах. Если вы хоть что-нибудь писали на Питоне, то вам доводилось пользоваться ими. Атрибуты объекта — это другие, связанные с ним, объекты, доступные через оперетор . (точка), например: >>> my_object.attribute_name. Кратко опишем поведение Питона при обращении к атрибутам. Это поведение зависит от типа объекта, доступного по атрибуту (уже поняли, что это относится ко всем операциям, связанным с объектами?).

В типе можно описать специальные методы, модифицирующие доступ к атрибутам его экземпляров. Эти методы описаны здесь (как мы уже знаем, они будут связаны с необходимыми слотами типа функцией fixup_slot_dispatchers, где создаётся тип… вы же прочитали предыдущий пост, так ведь?). Эти методы могут делать всё, что угодно; описываете ли вы свой тип на C или на Python, вы можете написать такие методы, которые сохраняют и возвращают атрибуты из какого-нибудь невероятного хранилища, если вам так угодно, вы можете передавать и получать атрибуты по радио с МКС или даже хранить их в реляционной базе данных. Но в более-менее обычных условиях эти методы просто записывают атрибут в виде пары ключ-значение (имя атрибута/значение атрибута) в каком-нибудь словаре объекта, когда атрибут устанавливается, и возвращают атрибут из этого словаря, когда он запрашивается (или выбрасывается исключение AttributeError, если в словаре нет ключа, соответствующего имени запрашиваемого атрибута). Это всё так просто и прекрасно, спасибо за внимание, на этом, пожалуй, закончим.

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

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

Продолжаем перевод цикла статей о внутренностях Питона. Если вы хоть раз задавались вопросом «а как же оно устроено?», обязательно читайте. Автор проливает свет на многие интересные и важные аспекты устройства языка.

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

Когда я размышляю о реализации Питона, я представляю себе огромный конвейер, по которому движутся коды машинных операций, которые затем попадают в гигантский завод, где повсюду возвышаются градирни и башенные краны, — и меня просто переполняет желание подойти поближе. В этой части мы поговорим о структурах состояния интерпретатора и состояния потока (./Python/pystate.c). Сейчас нам нужно заложить фундамент, чтобы потом было легче понять, как исполняется байткод. Совсем скоро мы узнаем, как устроены фреймы, пространства имён и объекты кода. Но для начала давайте поговорим о тех структурах данных, которые связывают всё воедино. Учтите, я предполагаю наличие хотя бы поверхностного понимания устройства операционных систем и знания хотя бы таких терминов, как ядро, процесс, поток и т. п.

Во многих операционных системах пользовательский код исполняется в потоках, которые живут в процессах (это верно для большинства *nix-систем и для «современных» версий Windows). Ядро ответственно за подготовку и удаление процессов и потоков, а также за определение того, какой поток на каком логическом CPU будет исполняться. Когда процесс вызывает функцию Py_Initialize, на сцену выходит другая абстракция, интерпретатор. Любой Python-код, запускаемый в процессе, привязан к интерпретатору. Об интерпретаторе можно думать как об основе всех прочих концепций, которые мы будем обсуждать. Питон поддерживает инициализацию двух (и более) интерпретаторов в одном процессе. Несмотря на то, что эта возможность редко используется на практике, я буду её учитывать. Как было сказано, код исполняется в потоке (или потоках). Не исключение и виртуальная машина Питона (VM). При этом сама VM имеет поддержку потоков, т.е. у Питона есть своя абстракция для представления потоков. Реализация этой абстракции полностью полагается на механизмы ядра. Таким образом, и ядро, и Питон имеют представление о каждом из Python-потоков. Эти потоки управляются ядром и исполняются как отдельные потоки параллельно всем прочим потокам в системе. Ну… почти параллельно.

До сих пор мы не обращали внимания на слона в нашей посудной лавке.

Сколько памяти занимает 1 миллион целых чисел?

Меня часто донимали размышление о том, насколько эффективно Python использует память по сравнению с другими языками программирования. Например, сколько памяти нужно, чтобы работать с 1 миллионом целых чисел? А с тем же количеством строк произвольной длины?
Как оказалось, в Python есть возможность получить необходимую информацию прямо из интерактивной консоли, не обращаясь к исходному коду на C (хотя, для верности, мы туда все таки заглянем).
Удовлетворив любопытство, мы залезем внутрь типов данных и узнаем, на что именно расходуется память.

В последнюю пятницу октября в Минске традиционно прошел Python Meetup, на котором вприкуску с бургерами были зачитаны три доклада от спецов из компаний Viber, Melesta и Wargaming.net. На этот раз прошлись по недостаткам Python, разобрались на примере, с какими проблемами можно столкнуться при портировании на Python, а также рассмотрели все этапы разработки серверов на Python для социальных игр. Все видео, а также ссылки на презентации можно найти чуть ниже.

Питон изумителен.

Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).

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

При работе с Питоном я столкнулся с кучей таких технологий. Инструменты *ython. Но лишь недавно я уделил время, чтобы разобраться, что они собой представляют, как они работают и почему они (каждая по-своему) необходимы.

В этом посте я начну с нуля и пройдусь по разным реализациям Питона, а закончу подробным введением в PyPy, за которым, по моему мнению, будущее языка.

Все начинается с понимания того, чем на самом деле является “Питон”.

Английский разработчик Дэмьен Джордж (Damien George) сегодня официально объявил о выпуске Micro Python — эффективной реализация Python 3 для встроенных систем с малым объёмом оперативной памяти. Разработка этой версии началась в декабре, после удачной кампании по сбору средств на выпуск Pyboard — контроллера, работающего на Питоне.

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

Можно сказать совершенно точно: Python не является идеальным языком программирования. На мой взгляд, основные проблемы вытекают из особенностей интерпретатора и мало связаны с самим языком, однако все эти нюансы интерпретатора постепенно становятся частью самого языка, и поэтому они так важны.

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

Одна из отличительных особенностей языка Python — это посвящённые этому языку конференции, так называемые PyConы. Не так давно мне удалось побывать на одном таком PyCon-е — EuroPython 2014. EuroPython — это одна из наиболее крупных европейских ежегодных конференций по языку Python, которая три последних года проводилась во Флоренции, а в 2014м — первый раз в Берлине. Пока свежи воспоминания решил написать небольшой отчётик — что и как было.

Это вторая часть моих размышлений на тему «Python, каким бы я хотел его видеть», и в ней мы более подробно рассмотрим систему типов. Для этого нам снова придётся углубиться в особенности реализации языка Python и его интерпретатора CPython.

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

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

Практически все API, которые я реализовывал на Python, не работали в других языках программирования. Даже такая простая вещь, как интерфейс для работы с командной строкой (библиотека click) просто не работает в других языках, и основная причина в том, что вам приходится беспрестанно бороться с типами данных.

Не так давно поднимался вопрос добавления статической типизации в Python, и я искренне надеюсь, что лёд, наконец, тронулся. Постараюсь объяснить, почему я против явной типизации, и почему надеюсь, что Python никогда не пойдёт по этому пути.

В этой статье я покажу, как написать рудиментарный, нативный x86-64 just-in-time компилятор (JIT) на CPython, используя только встроенные модули.

Код предназначен для UNIX-систем, таких как macOS и Linux, но его должно быть легко транслировать на другие системы, типа Windows. Весь код опубликован на github.com/cslarsen/minijit.

Цель — сгенерировать в рантайме новые версии нижеприведённого ассемблерного кода и выполнить их.

48 b8 ed ef be ad de  movabs $0xdeadbeefed, %rax
00 00 00
48 0f af c7           imul   %rdi,%rax
c3                    retq

В основном, мы будем иметь дело с левой частью кода — байтовой последовательностью 48 b8 ed ... и так далее. Эти 15 байтов в машинном коде составляют функцию x86-64, которая умножает свой аргумент на константу 0xdeadbeefed. На этапе JIT будут созданы функции с разными такими константами. Такая надуманная форма специализации должна продемонстрировать базовую механику JIT-компиляции.

Всем привет! Это уже восемнадцатый выпуск дайджеста на Хабрахабр о новостях из мира Python.

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

Итак, поехали!

Всем привет! Это уже девятнадцатый выпуск дайджеста на Хабрахабр о новостях из мира Python.

Присылайте свои интересные события из мира Python. Вместе мы сделаем Python еще лучше:)

Итак, поехали!

В Python, есть два похожих типа — список (list) и кортеж (tuple). Самая известная разница между ними состоит в том, что кортежи неизменяемы.

Вы не можете изменить объекты в tuple:

>>> a = (1,2,3)
>>> a[0] = 10
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment

Но вы можете модифицировать изменяемые объекты внутри кортежа:

>>> b = (1,[1,2,3],3)
>>> b[1]
[1, 2, 3]
>>> b[1].append(4)
>>> b
(1, [1, 2, 3, 4], 3)