У async/await возможно будущее вместе с субинтерпретаторами. На видео мы как раз целый блок про такое говорим. В будущем, возможно, получится скейлить asyncio через создание доп субинтерпретаторов. У threading - тоже все хорошо. Free-threading и субинтерпретаторы можно и нужно использовать вместе. О чем тоже есть в видео. У мультипроцессинга, кажется, будут некоторые проблемы. Ведь его юзкейсы полностью покрыты. С точки зрения библиотек – я тоже описал, что можно сделать что-то высокоуровневое, вроде actix в rust, чтобы использовать в прикладных приложениях
Я запустил без особых проблем 10к штук на маке м2. Сколько максимум – я не знаю. Надо замерять отдельно. Почему вы решили, что основные проблемы не пофиксили? Вроде бы я как раз описал, что все проблемы как раз таки пофиксили.
ценности в том, чтобы затаскивать что-то в stdlib - не очень много. туда стоит затаскивать только штуки, которые точно не будут меняться. мы надеемся, что файловые системы когда-то смогу стать асинхронными. так что тащить в stdlib хак - не самое лучшее решение; пусть будет отдельным пакетом
Простите, я не понял вопрос. Мы же в рамках одного процесса работаем. Файловый дескриптор - просто int, его можно шарить между субинтерпретаторами легко. Про мьютексы - я не понимаю без примера :)
Сразу возникает вопрос: а такую структуру как обрабатывать? [[[1], [2]], [3]], что вернет .flat? Кажется, что itertools дает полную гибкость в решении данной задачи.
Еще раз спасибо. Сел разбирать отчет. Вот результаты:
Все проблемы в _hacl уже исправлены в main (3.14.0a7+)
Убрать if (fut->fut_state != STATE_PENDING) нельзя, потому что перед второй проверкой идет потенциальный вызов Python кода PyObject_CallNoArgs(exc); – он может изменить весь C стейт
Аналогично с `start_state != deque->state` – там идет вызов `PyObject_RichCompareBool`
В целом можно заменить if (error_handler == PyERROR_UNKNOWN) на `assert(errors != PyERROR_UNKNOWN);`, но не могу назвать данное поведение ошибкой. get_error_handler_wide может начать возвращать PyERROR_UNKNOWN в любой момент
Нельзя назвать ошибкой и get_datetime_capi();, потому что сейчас там скорее хак, который не совсем корректно работает. Будет в скором временем более сложная конструкция, которая сможет вернуть NULL, но позже. Заранее иметь проверку – норм
PyXIFreeNamespace(_PyXI_namespace *ns) – можно отрефакторить, да. Но там нет ошибки, обычно PRы с просто рефакторингом - не очень охотно принимают
FStar_UInt128_u32_combine_ – не является часть CPython, а частью HACL. можно открыть багу туда. Но опять же, ошибки нет :(
`val = -1;` можно удалить, но опять же – не ошибка. Просто лишняя строка :)
Нет, у меня нет статусбара :)
Но для тех, кто пользует статусбар - прикольная идея! Спасибо!
я не согласен, но у всех у нас есть право пользоваться тем, чем нам нравится, как нам нравится :)
Спасибо за статью!
У async/await возможно будущее вместе с субинтерпретаторами. На видео мы как раз целый блок про такое говорим. В будущем, возможно, получится скейлить asyncio через создание доп субинтерпретаторов. У threading - тоже все хорошо. Free-threading и субинтерпретаторы можно и нужно использовать вместе. О чем тоже есть в видео. У мультипроцессинга, кажется, будут некоторые проблемы. Ведь его юзкейсы полностью покрыты. С точки зрения библиотек – я тоже описал, что можно сделать что-то высокоуровневое, вроде actix в rust, чтобы использовать в прикладных приложениях
Я запустил без особых проблем 10к штук на маке м2. Сколько максимум – я не знаю. Надо замерять отдельно. Почему вы решили, что основные проблемы не пофиксили? Вроде бы я как раз описал, что все проблемы как раз таки пофиксили.
каждый субинтерпретатор – отдельный OS тред. их работой управляет шедулер OS.
вы сами отправляете в субинтерпретатор данные. если вы что-то явно не пошарили – оно и не пошарится. не отправите файл – к нему не будет доступа
да, субинтерпретаторы оригинально появились в python1.5. но зачем слушать автора, когда можно сразу написать остроумный коментарий? :)
ценности в том, чтобы затаскивать что-то в stdlib - не очень много. туда стоит затаскивать только штуки, которые точно не будут меняться. мы надеемся, что файловые системы когда-то смогу стать асинхронными. так что тащить в stdlib хак - не самое лучшее решение; пусть будет отдельным пакетом
Простите, я не понял вопрос. Мы же в рамках одного процесса работаем. Файловый дескриптор - просто
int, его можно шарить между субинтерпретаторами легко. Про мьютексы - я не понимаю без примера :)асинхронные операции с файлами и
aopenтак и не добавили в сам питон. понятно почему, но все равно забавно.спасибо! тоже очень жду actix на питоне!
Крутая статья, спасибо!
Вы забыли указать, что вы делаете перевод статьи: https://labs.quansight.org/blog/free-threaded-one-year-recap
Сразу возникает вопрос: а такую структуру как обрабатывать?
[[[1], [2]], [3]], что вернет.flat? Кажется, чтоitertoolsдает полную гибкость в решении данной задачи.Дублирую тут https://github.com/python/cpython/pull/132662/files#diff-4903ddce642a378ef03f37f72332cf1f5acb5bb0c6247669145fc3d8ea7cd43e Там гитхаб может тупить + нужно разворачивать изменения в UI.
Еще раз спасибо. Сел разбирать отчет. Вот результаты:
Все проблемы в
_haclуже исправлены вmain(3.14.0a7+)Убрать
if (fut->fut_state != STATE_PENDING)нельзя, потому что перед второй проверкой идет потенциальный вызов Python кодаPyObject_CallNoArgs(exc);– он может изменить весь C стейтАналогично с `start_state != deque->state` – там идет вызов `PyObject_RichCompareBool`
В целом можно заменить
if (error_handler ==PyERROR_UNKNOWN)на `assert(errors != PyERROR_UNKNOWN);`, но не могу назвать данное поведение ошибкой.get_error_handler_wideможет начать возвращатьPyERROR_UNKNOWNв любой моментНельзя назвать ошибкой и
get_datetime_capi();, потому что сейчас там скорее хак, который не совсем корректно работает. Будет в скором временем более сложная конструкция, которая сможет вернутьNULL, но позже. Заранее иметь проверку – нормPyXIFreeNamespace(_PyXI_namespace *ns)– можно отрефакторить, да. Но там нет ошибки, обычно PRы с просто рефакторингом - не очень охотно принимаютFStar_UInt128_u32_combine_– не является часть CPython, а частью HACL. можно открыть багу туда. Но опять же, ошибки нет :(`val = -1;` можно удалить, но опять же – не ошибка. Просто лишняя строка :)
А вот
i < input_length– реальная ошибка, спасибо. Поправил https://github.com/python/cpython/issues/132769Файл pyshellext.cpp говорит, что поддерживает Vista. https://github.com/python/cpython/blob/132b6bc98f47a4d897dead8635b5a50a0baee485/PC/pyshellext.cpp#L1 Но тут я не знаю, не шарю за винду, первый раз вижу данный файл :) Можно открыть обсуждение.
В итоге – действительно проблемных кусков кода, вроде бы, к счастью не было :)
Добрый день, спасибо за анализ. Забрал в работу.
Сергей, отличные PRы, мое уважение :)
Кирилл – красавчик! Желаю успехов в карьере :)
PyList_NewиPy_BuildValueоба могут вернутьNULL. Лучше использоватьPyList_SET_ITEMвместоPyList_SetItemв данном случае.