sobolevn31 июл в 13:27

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

Средний

6 мин

11K

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

Дайджест

+46

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

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-строками.

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}` не будет. Не думаю, что тут могут возникнуть проблемы.

test4354545 31 июл в 18:22

Как будто fdict(ну или frozen_dict) вместо f более явно выражало бы суть. А то как то совсем не по дзену питона

sobolevn 31 июл в 18:36

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

test4354545 31 июл в 19:07

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

sobolevn 31 июл в 20:02

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

test4354545 31 июл в 22:44

Никак, поэтому и топлю за то чтобы подобного было как можно меньше, а не больше :)

sobolevn вчера в 06:10

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

morijndael вчера в 09:28

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

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

А литерал:

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

sobolevn вчера в 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 вчера в 01:44

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

sobolevn вчера в 06:08

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

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

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

morijndael вчера в 09:33

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

sobolevn вчера в 10:10

dambung_tsss 🌚️️

zapparello2 вчера в 14:32

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

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

aero2210 вчера в 15:46

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

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

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

zapparello2 вчера в 18:22

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

sobolevn 22 часа назад

Мешает :(

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

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

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

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

zzzzzzerg вчера в 17:43

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

zapparello2 вчера в 18:36

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

sobolevn 23 часа назад

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

zzzzzzerg 22 часа назад

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

sobolevn 23 часа назад

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

pda0 12 часов назад

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

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

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

sobolevn 6 часов назад

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

pda0 6 часов назад

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

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

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