Рубрика «cpython»

В 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)

Читать полностью »

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

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

С предыдущим digest можно ознакомиться здесь

Читать полностью »

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

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

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

Читать полностью »

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

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

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

Читать полностью »

В этой статье я покажу, как написать рудиментарный, нативный 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, каким бы я хотел его видеть», и в ней мы более подробно рассмотрим систему типов. Для этого нам снова придётся углубиться в особенности реализации языка Python и его интерпретатора CPython.

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

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

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

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

Читать полностью »

Disclaimer: это перевод статьи Армина Ронашера «The Python I Would Like To See».

Вступление

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

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

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

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

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

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

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

image

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

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

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

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

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

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