Как вы могли знать, уже два года идет вялотекущий перевод питона на поддержку независимых интерпретаторов в одном процессе.
https://github.com/ericsnowcurrently/multi-core-python
https://www.python.org/dev/peps/pep-0554/
По ходу дела всплывают спящие баги, которые были в интерпретаторе годами, но их никто не исправлял, потому что они не проявлялись до этого. Постепенно глобальные переменные в интерпретаторе вычищаются вилкой - можно ожидать, что через годик-другой реализацией независимых интерпретаторов в одном процессе можно будет пользоваться.
Теперь главный вопрос: зачем? PEP 554 предлагает обращаться за помощью к каналам, как в Go, но:
- каналы как средство взаимодействия потоков убоги даже в Go;
- в питоне уже есть multiprocessing, который по сути и есть развитая идея каналов с возможностью прокинуть в обе стороны вызов функции и запрос атрибутов объекта, вплоть до итераторов, но не более того.
Для людей, которые уже готовы отвечать «ну дык есть же многопроцессы, есть форк на никсах - вот и используйте их», напомню, что реализация форка процесса на уровне ОС-и в действительности мало помогает многоПРОЦЕССовости питона - машем ручкой сборщику мусора, который передергивает счетчики ссылок:
https://instagram-engineering.com/dismissing-python-garbage-collection-at-ins...
>>> import os, sys, gc
>>> len(gc.get_objects())
6888Допустим, у нас уже есть несколько независимых потоков интерпретатора. Логичное желание - придумать какие-то эффективные модели взаимодействия интерпретаторов, которыми кто-то захочет пользоваться.
Примитивные ячейки данных (вроде многопоточного bytearray или других настраиваемых структур) довольно бесполезны, потому что мы же пользуемся питоном для того, чтобы взмыть вверх по абстракциям. Если же мы надумаем передать через подобнюу структуру хотя бы элементарную функцию, вроде
def hello():
return "hello world"Можно замутить атомарные операции на питоне, которые будет писать сам пользователь для описания превращений сложных структур, но есть проблема с побочными эффектами и гарантией потокобезопасности, потому что:
- любая функция в питоне использует все вышестоящие контексты, а также имеются замыкания, которые могут использовать свои собственные контексты;
- в CPython довольно сложно понять, работает ли функция с побочными эффектами или без онны. Речь не только про код на питоне, но еще и про код на си.
Для решения проблемы со стандартными бибиотеками и сборщиком мусора сообразительные люди довольно быстро придумали Jython, позже - IronPython, а потом и PyPy. Все три реализации привязывают вас к соответствующей среде выполнения, и это неприкольно даже несмотря на возможность выйти из них в расширения на C или других языках - проще написать уже всё на крестах или жабе, чем морочиться с пирамидами языков.
В итоге, на текущий момент, многопоточная разработка сводится к настройке внешних по отношению к питону потоков, как то сделано в NumPy, а потому разработать отзывчивый GUI на одном питоне не получится, например.
Кто-то видит свет в конце тонеля? Или же это предсмертные видения?
