Слушайте, я все понимаю, но бомбическая новость про *Python* это например если бы из него внезапно GIL выпилили, или ускорили в 10 раз. А это просто анонс мероприятия, возможно хорошего, возможно про Python

Зачем выпиливать GIL?

There are two genders

Окок
У всех в своем возрасте свои ценности
У меня ценность - нетворкин вокруг Python с крутыми англоязычными спикерами из международных компаний
Кто-то, наверняка, уже на столько крут, что это уже не интересно и не важно

А зачем его не выпиливать?

Спасибо, Кэп, но я знаю зачем нужен GIL и как он работает. Я спросил, почему его не нужно выпиливать?

Может быть потому что он нужен, не? Выполняет полезную фукцию?

Чем полезную? А что если я скажу, что его скоро могут выпилить? И мы не потеряем в производительности однопоточных приложений?

Я же уже кидал ссылку

https://github.com/colesbury/nogil

https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit

Этим занимаются core devs, поэтому шанс есть и обоснование и подход оставляют надежду. Это не gilectomy

Не все приложения однопоточные

Не знаю, что даже ответить.

Если не лень, сходи по ссылкам, почитай, что написали умные люди. Если после этого останутся аргументы, зачем нужен GIL если можно без GIL, то можно продолжить дискуссию. :)

The GIL is a major obstacle to concurrency. For scientific computing tasks, this lack of concurrency is often a bigger issue than speed of executing Python code, since most of the processor cycles are spent in optimized CPU or GPU kernels. The GIL introduces a global bottleneck that can prevent other threads from making progress if they call any Python code.

In the “Why Swift for Tensorflow” doc, Chris Lattner writes “the GIL increases complexity throughout the stack in large scale settings: it prevents model authors from achieving reasonable performance for some things (without themselves writing C++/CUDA), and prevents natural expression of concurrent algorithms in a model.”

A lot of engineering effort has gone into working around the GIL. One of the consequences of this is that it’s unlikely that simply removing the GIL will magically speed-up existing code. However, I believe that removing the GIL will make it easier to take advantage of parallelism, simplify development of new libraries, and allow us to improve existing libraries.

ну да. и GIL по сути запрещает эффективно использовать несколько ядер процессора в одном процессе, приходится с multiprocessing извращаться

Поэтому я не очень понимаю, какие могут быть аргументы за то, чтобы оставить GIL если есть реальный шанс избавиться от такого костыля и получить полноценную многопоточность в любом питоновском коде.

Можно привести аналогию. Человек, который не может ходить, ездит на инвалидном кресле. Кресло несомненно полезно для него, но что если появится возможность поставить человека на ноги, неужели кто-то в здравом уме будет этому противиться и требовать оставить инвалидное кресло?

Риски отказа от GIL тоже вполне понятны, о них написано в статье. Но что если получится? Это же будет прекрасно. Люди только спасибо скажут, даже те, кто никогда не задумывался раньше о синхронизации потоков. 😀

Я тоже побуду душнилой.  Но когда прочитал бомбическая новость ожидал чего-то бомбического в не митап.

Но принято))

Есть очевидная причина: выпилив gil куча разработчиков столкнётся с дивным миром многопоточности и изранится в кровь и ноги ))

У меня глупый/странный вопрос: а какой практический смысл спрашивать на собесах разницу между asyncio.Task vs asyncio.Future?

А что, кто-то спрашивает? :)

Никакого, конечно. Примерно так же как спрашивать: назовите все методы класса A из b.c.d.

Спрашивали бы хотя бы про разницу между asyncio и trio, хотя и в этом смысла не сильно больше. Общие вопросы по теории асинхронности, кооперативности, подводных камнях и т.п. вещах имеют смысл. Вопросы про детали реализации и особенности использования конкретной библиотеки - это всегда скучно и чаще бестолково.