sobolevn31 июл в 13:27

Находки в опенсорсе: мир питона за июль 2026

Средний

6 мин

14K

Python * Программирование *

Дайджест

+57

Комментарии 63

banno 31 июл в 13:41

Стало выглядеть как f строки

sobolevn 31 июл в 14:00

Да, таков наш план. Вот тут было первое голосование https://discuss.python.org/t/frozenset-and-frozendict-comprehensions/101584/48 Люди хотят, чтобы было похоже на f строку :) Я сам был за $

vldmrmlkv 31 июл в 17:58

А если токен будет из двух букв - это нарушает какое-то соглашение в таких случаях или так исторически так сложилось? fo от frozen object тоже нормально и нет путаницы с f-строками.

Enchant 6 авг в 22:11

Если не зацикливаться именно на буквах, то токен уже состоит из двух конкретных символов:

f" или f' — токен начала f-строки
f{ — токен начала frozedict или frozenset

Для LLM и машинного поиска (e.g. grep) такой токен отлично различим, для человека — ну, думаю, привыкнуть можно быстро.

iroln 31 июл в 19:50

А зачем люди хотят, чтобы было похоже на f-строку? Синтаксический маркер f уже используется в контексте строк. А теперь у этого маркера будут разные синтаксические роли в зависимости от типа литерала. Это по сути контекстно-зависимая семантика. И это выглядит как-то неоднозначно. Я бы так не делал.

sobolevn 31 июл в 20:01

Я не знаю, почему люди так хотят :)

Как я писал выше, я был за $. Но демократия решила иначе.

danilovmy 31 июл в 20:22

Вот тут было первое голосование https://discuss.python.org/t/frozenset-and-frozendict-comprehensions/101584/48
Люди хотят, чтобы было похоже на f строку :) Я сам был за $

прочел все 75 комментариев. Люди хотят frozenset(...) and frozendict(...) offer much clearer mnemonic value. Зачем вводить f{}, когда возможно очевидное frozenset(iterable) непонятно. кстати предложенный {}.frosen(), кмк, идеальный вариант.

Но, собственно, где я и где python...

sobolevn 31 июл в 20:36

Но ведь frozenset(iterable) не позволяет нормально оптимизировать код. В обсуждении по ссылке как раз есть примеры, почему так сделать нормально не получится. Сравните опкоды `frozenset({1, 2})` и `frozenset((1, 2))`. В том же обсуждении есть примеры, почему .take_frozenset и .take_frozendict не могут быть единственными дешевыми конструкторами. Например: при многострочных выражениях - непонятно, какой тип будет у объекта до самого конца. И другие важные штуки.

ryann 31 июл в 14:40

It is interesting

danilovmy 31 июл в 15:19

дичь конечно, но как есть:
почему не упростить синтаксис до mydict.take_frosen() myset.take_frosen(). тогда я могу нормально работать с getattr(obj, "take_frosen")() или по какой то причине необходимо использовать разные названия для одного и того же действия?
почему не стали использовать что нибудь типа myset as frosen?
Как будет проверяться что frosen? будет ли if myset is frosen:

Форматтер строки к сетам/диктам.... о да, ~~это прекрасно~~ нет. Это же очередной выстрел в ногу. Потому что у строки есть/был u'', f'', r'', t'' и теперь f'' будет у dict но он делает не то что вы полумали. а с автодополнением f{1,2,3} в vscode превратится в строку... "1,2,3" и никак не в фрозенсет.

sobolevn 31 июл в 17:04

Я почти ничего не понял :)

set.take_frozenset и dict.take_frozendict - разные методы для разных типов. их названия точно отражают то, что происходит внутри. Зачем сокращать названия builtin классов - не очень понятно.

почему не стали использовать что нибудь типа myset as frosen?

Потому что в питоне нет концепции кастов. as используется для создания имен, а не типов. Добавлять такое - точно не надо :)

Как будет проверяться что frosen?

Не очень понял вопрос. Как и сейчас? isinstance(obj, frozenset)

Форматтер строки к сетам/диктам

Нет, форматтер строки тут не при чем. Мы добавляем новый токен f{, который называется FLBRACE, по аналогии с { (LBRACE).

а с автодополнением f{1,2,3} в vscode превратится в строку

Автодопонение будет работать корректно. Сейчас же `{1, 2, 3}` не превращается в строку. И `f{1, 2, 3}` не будет. Не думаю, что тут могут возникнуть проблемы.

НЛО прилетело и опубликовало эту надпись здесь

sobolevn 31 июл в 18:36

я не думаю, что тут есть реальная проблема. вы же просто помните, что {} - словарь; вот так же и f{} - иммутабельный словарь.

НЛО прилетело и опубликовало эту надпись здесь

sobolevn 31 июл в 20:02

Как знание английского языка помогает вам понять `{1: 2}`? В чем принципиальное отличие от `f{1: 2}`?

НЛО прилетело и опубликовало эту надпись здесь

sobolevn 1 авг в 06:10

Спасибо за вашу обратную связь! Вашу позицию не разделяю, но уважаю :)

morijndael 1 авг в 09:28

да, но компилироваться это будет примерно в следующее:

найти имя fdict в локальных/нелокальных/глобальных переменных
проверить, что его вообще можно вызвать
закинуть аргументы на стек
вызвать функцию
функция на C создаст нужный объект дергая внутренности интерпретатора

А литерал:

закинуть аргументы на стек
создать объект сразу нужным опкодом

sobolevn 1 авг в 10:09

Вы совершенно правы :) Сейчас есть похожая штука: сравните

» ./python.exe -m dis <<< 'dict(a=1, b=2)'      
  0           RESUME                   0

  1           LOAD_NAME                0 (dict)
              PUSH_NULL
              LOAD_SMALL_INT           1
              LOAD_SMALL_INT           2
              LOAD_CONST               1 (('a', 'b'))
              CALL_KW                  2
              POP_TOP
              LOAD_COMMON_CONSTANT     7 (None)
              RETURN_VALUE

И:

» ./python.exe -m dis <<< '{"a":1, "b": 2}'  
  0           RESUME                   0

  1           LOAD_CONST               0 ('a')
              LOAD_SMALL_INT           1
              LOAD_CONST               1 ('b')
              LOAD_SMALL_INT           2
              BUILD_MAP                2
              POP_TOP
              LOAD_COMMON_CONSTANT     7 (None)
              RETURN_VALUE

Вроде разница не очень большая, но: BUILD_MAP работает так:

inst(BUILD_MAP, (values[oparg*2] -- map)) {
    PyObject *map_o = _Py_BuildMap_StackRefSteal(values, oparg);
    DEAD(values);
    ERROR_IF(map_o == NULL);
    map = PyStackRef_FromPyObjectStealMortal(map_o);
}

Где _Py_BuildMap_StackRefSteal делает тоже самое, что и простой вызов _PyDict_FromItems. Ну а CALL_KW - один из самых медленных опкодов вообще.

vasily-v-ryabov 31 июл в 20:52

Всё хорошо. Только метод назвал бы не take_frosendict, а as_frosendict. То же самое для frozenset. Так как-то понятнее и короче.

Ну, или хотя бы to_frozendict. Просто take - взять, а тут вроде отдавать надо. Поэтому и корёжит.

zzzzzzerg 31 июл в 21:04

У take семантика забрать значения, у as оставить на месте и вернуть копию. Можно было бы использовать steal, но от него решили отказаться в пользу существующего прецедента в bytearray.

aero2210 1 авг в 01:44

to_frozen по аналогии с int.to_bytes

sobolevn 1 авг в 06:08

to_bytes не уничтожает существующий int, а просто конвертит его. а тут нужен явный глагол, который бы показывал, что само левое значение обнулится:

>>> b = bytearray(b'123')
>>> b
bytearray(b'123')
>>> b.take_bytes()
b'123'
>>> b
bytearray(b'')

В питоне такое назвали take_* :)

morijndael 1 авг в 09:33

надо было назвать yoink_* , с ним сразу понятно что происходит с содержимым :D

sobolevn 1 авг в 10:10

dambung_tsss 🌚️️

vasily-v-ryabov 6 авг в 08:34

Вот оно что! Теперь тейк понятен ) Было неочевидно, что это именно взятие с уничтожением взятого. То есть что-то вроде move семантики в плюсах.

sobolevn 7 авг в 18:50

Да, что-то в таком духе :)

zapparello2 1 авг в 14:32

А в чём смысл вообще неизменяемых словарей? Структура данных точно такая же, производительность не изменилась ни на йоту. Чем оно принципиально отличается от Final[dict]? А так-то эти "оптимальные" take_somthing сильно смахивают на переливание из пустого в порожнее.

А может, наконец, настала пора сделать нормальные константы в Питоне?
А то в крайне требовательных к производительности местах приходится использовать константы 1,2,3 не то что вместо IntEnum, но даже вместо КОНСТАНТ в теле модуля.

aero2210 1 авг в 15:46

мое не экспертное мнение следующее:

как вы будете реализовывать константность? - Ну допустим через const, но в C это модификатор типа, который прописывается при объявлении переменной определенного типа, а Python в этом смысле концептуально отличается + вводить отдельную семантику для обозначения константности - опрометчиво.

+ Тут речь не про новые структуры данных, а про новый синтаксис для их литералов ;)

zapparello2 1 авг в 18:22

const нету, но есть
x: Final[int] = 1234
Понятно, что на сегодняшний день это syntax sugar, но никто не мешает сделать, чтобы оно наконец заработало как положено. И при ссылке на x сразу в псевдокод вставляло прям число а не вызов locals()["x"]

sobolevn 1 авг в 20:43

Мешает :(

Сейчас, мы не знаем, что такое Final в момент компиляции. Final может быть ваш собственный класс.

Аннотации могут быть ленивыми
Они могут быть строками
Они могут быть вообще не определены в рантайме в форме: if TYPE_CHECKING: from typing import Final

Как такое нормально превратить во что-то адекватное на шаге symtable? Я не знаю. И никто не знает :(

Да и проблему оно описанную в посте не решит; `d: Final = {1: 2}` все еще поддерживает (по текущей typing spec) все действия над dict, в том числе `d[3] = 4`.

zzzzzzerg 1 авг в 17:43

Для неизменяемых структур можно делать оптимизации связанные с использованием из нескольких потоков, например, снизить количество refcount операций и/или локов. Подсчет ссылок как в FreeThreaded версии, так и в GIL-enabled JIT версии все еще сильно влияет на производительность.

zapparello2 1 авг в 18:36

А, добрая старая боротьба за thread safety.
Жизнь показала переоценённость этой парадигмы, большинство фреймворков, в базовом варианте, используют кооперативную многозадачность и события, в силу предсказуемости и простоты использования. А потоки остались скорее для фонового выполнения независимых задач.
Но идея понятна, спасибо.

sobolevn 1 авг в 20:38

А еще их можно будет дешево шарить в субинтерпретаторах, да :)

zzzzzzerg 1 авг в 20:53

И раз уж зашел разговор - исключить из сборщика мусора!

zzzzzzerg 4 авг в 19:32

Что не заставило себя долго ждать gh-155176: Don't track frozendicts whose contents can never be tracked by the GC by aisk · Pull Request #155178 · python/cpython

sobolevn 1 авг в 20:37

Final не обозначет "иммутабельность", он обозначает "запрет" на re-assignment. Что разные вещи :) Суть frozendict в том, что его нельзя изменить. Такое очень полезно для большого количества задач. Например: данные request, которые пришли к вам от пользователя. Или какой-то контекст, настройки приложения, справочники, тд. Более того, с Free-Threading by default, такое станет еще нужнее. Я предлагаю начать готовиться заранее, а не срочно в 30м году все переделывать.

trankov 12 авг в 07:59

Вообще, это нигде явно не написано, но простые литералы 1-2-3 это уже и есть константы. У них у всех один и тот же id.

>>> id(1)
4321157912
>>> a = 1
>>> id(a)
4321157912

То есть то, что Вы хотите оптимизировать в данном Вами примере («константы 1,2,3»), создатели интерпретатора уже для Вас оптимизировали. Если я, конечно же, правильно понял Ваш пример.

zapparello2 13 авг в 06:39

В псевдокоде мы имеем LOAD_SMALL_INT 1 vs LOAD_GLOBAL 0 (ONE) что таки даёт значительную разницу по времени выполнения (второе - поиск по словарю)

trankov 13 авг в 09:30

Да, соглашусь — ну, если такие мощные требования к производительности, есть numpy, есть numba, в конце-концов, есть ctypes — для скриптового языка с динамической типизацией это и так довольно неплохо, он не для скоростной математики был придуман.

zapparello2 13 авг в 23:09

самое смешное, что типы ctypes работают примерно вдвое медленнее родного int. numpy страшно тяжёлый и тоже медленный на простых операциях, не перекладывающихся на массивное выполнение родного кода или даже на видеопроцессор. array лёгкий но малоразвит (нельзя даже прибавить смещение ко всем числам массива, например) и тоже вдвое медленнее. numba это вообще другой язык программирования встроенный в питон (примерно как webasm относится к javascript).

trankov 14 авг в 00:20

и?

zapparello2 15 авг в 07:57

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

trankov 15 авг в 11:03

Мне нечего ответить кроме как посоветовать форкнуть Питон и дописать туда константы.

pda0 2 авг в 07:26

Абсолютно знакомый синтаксис. Ведь мы просто добавили f (как frozen) перед существующими dict и set литералами.

fl = f[1, 2, 3, 4]

После этого в камментах началась резня... :)

sobolevn 2 авг в 12:58

К сожалению, f[1] - валидный синтаксис сейчас. Потому я и предлагал $. Но, люди отказались по причине (я не шучу): "мы не хотим $ как в php". Вот так программисты принимают технические решения 🌚️️

pda0 2 авг в 13:03

Я вообще про кортежи пытался пошутить...

А так да, - & скажут не хотим как в C++. Может предложить #? С идеей, что данные в клетке. Ни войти не выйти.

sobolevn 7 авг в 18:52

с # не выйдет :(

Потому что сейчас `#{1, 2}` - валидный комментарий.

zapparello2 13 авг в 23:12

может сделать универсальные суффиксы к литералам, как сделали в C++? (1,2,3)f не конфликтует с валидным синтаксисом.

trankov 12 авг в 10:24

А что же насчёт "_{...}" как в Python? )) или "_{...}_"?

zapparello2 13 авг в 06:50

⋯≔≡≣⫷⁅{“one”: 1}⁆⫸≣≡≕⋯

trankov 13 авг в 09:26

вы мне это зачем отправили?

zapparello2 13 авг в 23:00

так кросивее

zapparello2 13 авг в 06:40

Особенно доставляет frozen set f(1,2).

“Можно ли мне назвать свою функцию f()? - Можно, а зачем?”

homm 3 авг в 19:40

dict.take_frozendict и set.take_frozenset

Ужасные названия. Почему не freeze?

sobolevn 3 авг в 21:29

Потому что они не делают freeze :) Они забирают данные из готовых мутабельных структур и создают новые иммутабельные.

homm 4 авг в 07:35

Вы имеете в виду, что сам объект не изменяется, а возвращается другой? Я не вижу тут проблемы, таких примеров в языке достаточно, например datetime.replace

sobolevn 4 авг в 21:39

Нет, как раз сам объект и изменяется:

>>> b = bytearray(b'123')
>>> b
bytearray(b'123')
>>> b.take_bytes()
b'123'
>>> b
bytearray(b'')

zapparello2 13 авг в 06:42

А bytes(b) делает копию или просто увеличивает счётчик ссылок? В смысле, в чём смысл take_bytes ?

sobolevn 13 авг в 14:00

Конечно, bytes(b) делает копию:

>>> b = bytearray(b'123')
>>> b2 = bytes(b)
>>> b.append(int.from_bytes(b'4'))
>>> b
bytearray(b'1234')
>>> b2
b'123'

Если данные большие - мы так делать не хотим :)

zapparello2 13 авг в 22:57

в Qt, например, все присваивания основных классов делаются через увеличение счётчика ссылок. И лишь при изменении одного из объектов создаётся копия (своеобразный copy-on-write).

QByteArray x = y; // x и y указывают на один блок данных

x.append(4); // вот тут x делает копию и дописывает 4

sobolevn 14 авг в 20:42

Переделывать существующие структуры в CoW - не так просто, если мы хотим сохранить стабильный ABI.

zapparello2 15 авг в 07:52

Согласен что CoW штука хрупкая, но на C++ основная проблема это указатели (и итераторы), коих в Питоне нет. Навскидку сложно, но на первый взгляд как будто ничего не мешает реализовать такое в CPython, если там такого уже нет, конечно.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий