Comments 46
В bugs.python.org/issue17005 единственное побуждение положить в functool аргументировано, что топологическая сортировка «is somewhat related to total ordering», но большого обсуждения куда бы лучше положить этот класс судя по всему не было.
Про GIL, если речь про www.python.org/dev/peps/pep-0554, то похоже он перенесен на 3.10 или позднее
Что происходит в выпиливанием GIL?
Да, для меня до сих пор самое большой разочарование в Питоне — картонная многопоточность.
Для I/O всякого подходит, для вычислений — извините, плодите процессы и пиклите данные тудя сюда.
Позор для современного языка… при этом не использовать его вариантов часто нет — тонны библиотек, особенно в сфере работы с данными — только на нём.
пиклите данные тудя сюдаТак уже в 3.8 завезли shared memory…
Не отследил, спасибо.
Но мне часто приходится писать для систем вроде RH/CentOS7 где Python 3.6 — предел мечтаний. Можно, конечно, собрать последний и забандлить его в venv, но иногда это не подходит по организационным причинам.
В любом случае — надо изучить насколько оно удобно.
Имхо пусть python остаётся гибким и выразительным языком. А многопоточный счёт лучше делать на golang, там для этого всё есть. Ну а если очень хочется многопоточности — есть асинхронность, что поможет в большинстве задач, типа web-бекенд, либо использовать многопроцессность, где для отстрела себе конечностей нужно приложить специальные усилия…
Гонки-то и с GIL тоже возможны. GIL позволяет разве что не сломать внутреннее состояние интерпретатора, а записать переменную невовремя из другого потока всё равно никто не мешает (как раз три дня назад дебажил одну гонку)
Мне вообще кажется, что попытки построить универсальный язык на все случаи жизни породило море уродов и нанесло в мир ИТ слишком много энтропии… Но это моё мнение.
Кстати, это причина которая привела к тому, что гугл остался на 2 и будет ее сам патчить.
А где можно об этом почитать? Вроде гугл задеприкейтил python2 и всеми силами мигрирует на python3.
Хотя есть факторы и в пользу старого языка. У меня есть большой проект сетевого общения (не HTTP), так там переход на Py3 замедлил скорость процентов на 10 из-за того, что после первичного парсинга байтового прихода с сети — идёт конверсия в строки и уже дальше работа с str (которая в нём unicode). Конечно, ускорение процессоров снивелирует эту регрессию, но всё равно как-то не очень хорошо…
Сейчас есть некоторый хайп вокруг Julia. Кто знает, может это и будет новым «питоном 4 для многопоточности».
А многопоточный счёт лучше делать на golang, там для этого всё есть.
Да я бы рад, но вот мне допустим нужно немного ML сделать, искать аномалии в Timeseries данных. Для этого мне надо обучить моделек и гонять forecast по новым данным. А это сильно CPU-bound задача.
В Go полторы библиотеки для этого и те, скорее всего, заброшены. В Питоне — дофигищи. Поэтому пришлось брать его и костылять там всё это в подпроцессах через (де)сериализацию туда-сюда. Потому что за 30 лет питонцы не осилили мультитрединг, не говоря уже о (ко/го)рутинах...
Так что, на мой взгляд, язык определяется его экосистемой — библиотеками и (упаси боже) фреймворками.
Но с ним, языком может пользоваться любой человек с общими знаниями о программировании (или даже без них).
Как обычно, как речь о питоне, так каждый встречный — программист. Будто на других языках "hello world" невозможно осилить...
1. GIL никак не мешает сделать гонки при некорректной работе, начиная с манипуляцией общими данными за пределами мьютекса. Они реже и менее проблемны, да — segfault не поймаете — но это заслуга языка с AMM, а не GIL.
2. На сейчас планы по выпиливанию GIL состоят в том, что в пределах одного процесса можно создать подпроцесс со своим пучком тредов и взаимодействовать с ним точно так же, как сейчас модуль multiprocessing делает это для отдельных процессов. Поэтому такая реализация ничего вам не сломает — просто для 99% кода можно будет заменить слово multiprocessing на его новый аналог.
Почему TopologicalSorter лежит в functools? Что тут функционального?
На правах шутки: Потому что это свалка для вещей, которые не нужны Гвидо.
Guido:
“I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added built-in sum() at the same time we demoted reduce() from a built-in to something in functools (which is a dumping ground for stuff I don’t really care about :-).”
Ускорены встроенные типы (range, tuple, set, frozenset, list) (PEP-590)
Не смог после прочтения Пепа сделать аналогичный вывод. Не могли бы немного конкретизировать?
Если я правильно понимаю, речь идет о том, что благодаря этому соглашению, ускорится производительность вызова, за счет того, что будет создаваться меньше промежуточных структур в процессе. В любом случае, это больше касается C API, а не разработки на CPython. Однако, это если кто-то лучше вник и может вкратце пояснить, будет круто
2. Использовать lstrip, rstrip:
'foobar'.lstrip(('foo',))
Но есть риск удалить больше чем нужно в случае, когда строка начинается с повторения префикса, а надо удалить только один.
Проблема lstrip даже не в повторениях, а в том, что он работает совсем иначе и использовать его как removeprefix/removesuffix нельзя, так что изменение довольно полезное.
>>> 'fbar'.lstrip('foo')
'bar'
>>> 'oooooobar'.lstrip('foo')
'bar'
>>> 'oofbar'.lstrip('foo')
'bar'
Самое главно забыли — больше не надо импортировать typing. Теперь можно делать так:
a: list[int] = []
Главное — чтобы больше не было моржовых операторов.
Новый класс functools.TopologicalSorter для топологической сортировки направленных ациклических графов
О! Здорово, а то мне самому пришлось писать.
Если вы не представляет зачем это — представьте вам нужно загрузить куда-то зависимые друг от друга вещи.
Ну например что-то A не может существовать без B.
что-то C не может существовать без A.
Что-то D не может существовать без A и без C.
Топологическая сортировка вам поможет добыть последовательность загрузки B, A, C, D.
>>> 2+3 5 >>> 2 == 3 False
а ваши примеры почему-то соответствуют такому:
2+3 >> 5 2 == 3 >> False
Это сурово анноит, прошу исправить примеры.
Объясните кто-нибудь, почему в питоне объединение 2х словарей настолько важно что под него целый оператор добавили?
Но всё-таки:
1. Периодически необходимость объединить два словаря возникает. Сейчас для этого приходится пользоваться костылями типа:
res = dict1.copy()
res.update(dict2)
2. Добавление нового оператора — не такое уж значительное изменение, чтобы для него нужна была очень веская причина.
3. Для множеств подобный оператор уже давно есть, а словари, по сути, просто множества с дополнительными значениями.
Что нового ожидается в Python 3.9