async и await (PEP-492) — попадут ли в Python-3.5 ?

А сколько пистонов вообще в пятилетку в среднем выпускается? Они план выполняют?

Я считаю что не попадёт. Буду рад ошибаться.

Будем надеяться, это модное говно в Python не попадёт.

зачем ты так..

Гвидо хочет это в 3.5, наверное есть шансы.

Андрей Светлов расписал всю ситуацию вокруг этого PEP здесь.

это модное говно в Python не попадёт.

Но ведь async-то попал, надо же его теперь «исправлять»...

это радует :) ! (написанное там)

--------------------------------------------------

если кто из Ъ читает тему , то скопипащю сюда:

Код на это дело уже есть, вылизываем и ловим блох.

Ван Россум захотел эту хрень видеть в 3.5 — и не важно что месяц до закрытия фич.

Главное Юра Селиванов уже сделал — патч в целом работает!

Python Core Developers поддерживают — никто не против, а многие очень даже за!

И, последнее. Гвидо не захотел быть соавтором. Потому что тогда нужно было бы искать рецензента (на PEP по typing замахался искать, Mark Shannon согласился к счастью). Гвидо желает быть reviewer для этого PEP — и наши шансы быть принятыми в 3.5 очень неплохие.

...

Я только прилетел и хотел обсудить with statement и asyncio — а тут Юрка со своим предложением по async/await. Вместе слепили что-то непротиворечивое, выловили Гвидо. И понеслась душа в рай — мастер то не против, и даже готов принять, если всё будет сделано, в 3.5. Юра за пару дней сделал работающий прототип — неимоверной производительности парень! Так и живем - веселимся.

Какие-то лишние сущности вносят в язык, yield/yield from и так достаточно.

эти ``yield from`` — слишком громоздкие :-)

async — явно укоротит строчки кода (особенно в with и for).

а так как этот PEP ещё и добавляет новые __a***__ — то это же вообще шикарно!

это вносит больше порядка в язык!

зачем нужны коостыли имитируемые генераторами\итераторми, если можно сделать вполне адекватные конструкции!?

и модуль types — тоже станет иметь больше порядка!

то есть теперь зелёные-нити — это отдельная сущность. и это хорошо! меньше всякой путанницы, потомучто итераторы\генераторы будут использоваться *ИМЕННО* как они и должны использоваться, а не для зелёных-нитей

Скажем проще, ни yield, ни async-await не нужны были бы, будь в питоне вычислительные выражения как в F#. Потому как частный случай общего решения, реализованного в F#. С некоторой натяжкой про async-await, но все же (что важнее: уже запущенная фоновая задача или вычисление того, что нужно еще запустить через пул потоков?)

...не нужны были бы, будь в питоне вычислительные выражения как в F#

а как там? приведи пару показательных hello-world`ов ? :-)

ура!

теперь PEP-0478 ссылается на PEP-492 ..

это отличная новость :-)

(дополнил текст темы..)

Тлдр. Кто-нибудь может пояснить, зачем вообще async и await?

Кто-нибудь может пояснить, зачем вообще async и await?

говоря вкрадце — получается чуть меньше кода (и код становится более наглядным).

(формально — ``async``\``await`` это лишь синтаксический сахар — не более того.. но фактически — сахар настолько сладкий, что это выглядет как неотъемлемая часть ядра языка!).

в том числе меньше кода когда ты хочешь использовать ``for`` или ``with`` — в асинхронном коде.

``async`` можно использовать в комбинации с разными конструкциями, и в каждом таком случае получается запись чуть более короче чем БЕЗ ``async`` :-) .. ну и меньше всяких лиспообразных скобочек :-)

Тлдр. Кто-нибудь может пояснить, зачем вообще async и await?

и ещё async-и-await  — позволят отделить понятие «Функция-Генератор» от понятия «Короутины».

до изобретения Пайсоновских async-и-await — считалось что «Короутины» это лишь частный случай от «Функции-Генератора».

а после изобретения — это будут разные сущности :-) .. я считаю семантически — это более верно!

теперь «Короутины» НЕ будут частным случаем от «Функции-Генератора».. но при желании всё также можно будет создать определённый-вид «Короутины», используя в том числе и «Функцию-Генератор».

вообщем: async и await (PEP-492) — попадут ли в Python-3.5 ? (комментарий)

https://www.python.org/dev/peps/pep-0484/ - нужно, а остальное - УГ бессмысленное.

хочешь сказать что возня с указанием типов — это прям так нужно в языке с утиной типизацией? :-)

по мне тык это не более чем приятный бонус :-) ..

бонус, который поможет занять своё свободное время псевдоважным делом — прописыванием типов :-D .. например в ситуациях, когда скучно и нечего делать :-)

хочешь сказать что возня с указанием типов — это прям так нужно в языке с утиной типизацией? :-)

Я хочу сказать, что утиная типизация - беспомощное говно, и наличие хоть чего-то более приличного будет Щастьем с большой «Щ».

а чё это ваще такое?

напиши хеловорд, чтобы можно было увидеть и умереть?

ps. до 2020 года использовать что-то python 2.7 не планирую. после 2020 - планирую... но не буду.

> хочешь сказать что возня с указанием типов — это прям так нужно в языке с утиной типизацией? :-)

Я хочу сказать, что утиная типизация - беспомощное говно, и наличие хоть чего-то более приличного будет Щастьем с большой «Щ».

тыг ведь люди которые выбирают для себя Python — они его и выбирают в том числе потому что там утиная типизация :-) ..

а так вообще ну есть же полно других языков (со статикой) — кто же насильно заставляет писать именно на Python?

люди которые выбирают для себя Python — они его и выбирают в том числе потому что там утиная типизация :-) ..

Да, бывают и такие печальные инциденты.

кто же насильно заставляет писать именно на Python?

Жизнь - сложная штука.

напиши хеловорд, чтобы можно было увидеть и умереть?

hello-world врядли смогу, так как нет у меня этой кастомизированной версии Пайсона..

могу только процитировать строчки кода из PEP :

async def read_data(db):
    data = await db.fetch('SELECT ...')
    ...

и:

class AsyncContextManager:
    async def __aenter__(self):
        await log('entering context')

    async def __aexit__(self, exc_type, exc, tb):
        await log('exiting context')

и это:

async def commit(session, data):
    ...

    async with session.transaction():
        ...
        await session.update(data)
        ...

ps. до 2020 года использовать что-то python 2.7 не планирую. после 2020 - планирую... но не буду.

«что-то кроме» ? %)

# P.S.: диплом экстрасенса мне подсказывает что именно этот смысл ты хотел передать. а написал наоборот :-)

конечно, к роме. всё лучшее - к роме

А тебе не пофиг? Меня например больше печалит type hinting

печалит type hinting

Почему печалит? ИМХО, это лучшее, что случилось с момента введения nonlocal.

Потому что выглядит это не по-питоновски.

А тебе не пофиг?

сразу как только будет релиз — начну активно использовать (в тех местах где я сейчас использую asyncio).

Потому что выглядит это не по-питоновски.

наверно этот type hinting — заценят любители IDE`шечек :)

при чём, я имею ввиду тяжеловестные IDE, которые готовы нагенерировать программисту тонны JAVA`подобного кода (теперь с бабановым Пайсоновским вкусом!)...

короче, жесть, да.. :-)

А тебе не пофиг? Но это риторический вопрос.

type hinting — заценят любители IDE`шечек :)

Бгг. Написать хинт руками Ъ-питонистам религия не позволит?

Бгг. Написать хинт руками Ъ-питонистам религия не позволит?

позволяет. но время-то ведь ценнее будет. :-)

ды и глаза мозолит.

для сложных типов — декларировать описания и придумывать для них названия.. тоже не за 3 секунды :)

Написать хинт руками Ъ-питонистам религия не позволит?

позволяет. но время-то ведь ценнее будет. :-)

Те, кто ценит время, первыми будут писать хинты.

для сложных типов — декларировать описания и придумывать для них названия.. тоже не за 3 секунды :)

Ты только что признался, что не понимаешь свои же программы.

Ты только что признался, что не понимаешь свои же программы.

понятия — «понимать» и «придумывать особый термин на каждый чих, и на каждую callback-функцию» — думаю это не одно и тоже :-)

именно поэтому я и не люблю интерпрайзные JAVA`подобные подходы.

в них всё слишком формализированно.

а ведь на самом деле (в реальности) когда я работаю с каким-то объектом — мне вообще пофигу какого он там типа, лиж бы он имел бы поведение как мне нужно!

понятия — «понимать» и «придумывать особый термин на каждый чих, и на каждую callback-функцию» — думаю это не одно и тоже :-)

Ну да, ну да. Собака тоже всё понимает, только сказать не может.

уколол меня! ну ладно! :-)

я твою суть понял — «давай названия любой сущности которую используешь»..

однако когда будешь писать очередной раз свою очередную программу — заметь (присмотрись внимательно!) что когда ты будешь очередной раз выдумывать название (термин) к новой определённой сущности, то зачастую ты будешь использовать различные СИНОНИМЫ одних и тех же языковых слов.

то есть ты возьмёшь два РАВНОЗНАЧНЫХ языковых синонима и задашь этим синонимам свои НЕодинаковые формальные смыслы (НЕодинаковые — в контексте архитектуры твоей программы).

а размышляя над структурой архитектуры программы — ты будешь думать в стиле «вот под этим синонимам я подразумеваю <этот> смысл, а под этим синонимом я подразумеваю <ДРУГОЙ> смысл.. это совсем разные слова.. блаблабла... <такой-то> и <такой-то> смысл»

и когда ты обнаружешь это — подумай внимательно, не высосал бы ты весь этот подход из пальца?

ведь в итоге опять-таки НАСТОЯЩИЙ смысл приходится опять-таки хранить в голове :-)

ну ладно, в C/C++/Java — необходимо делать эти формализации (даже если это высасано из пальца, всё равно это нужно сделать чтобы компилирование прошло успешно)..

но ведь Пайсон *свободен* от этих оков!

я твою суть понял — «давай названия любой сущности которую используешь»..

Нет. Скорее «знай все сущности, которые используешь». Или, по крайней мере, умей вспомнить любую.

[...]

Даже не знаю, что ответить на эту мистику.

Даже не знаю, что ответить на эту мистику.

ну ответь например — "хорошо.. в предь я буду стараться на Пайсоне писать в более Пайсоновском стиле, и пытаться думать как Пайсон-программист! (и не буду пытаться Пайсон — превратить в другой язык..)" :-)

«хорошо.. в предь я буду стараться на Пайсоне писать в более Пайсоновском стиле, и пытаться думать как Пайсон-программист!» :-)

Я умею и то, и другое. Но, в отличие от тебя, я знаю и ограничения и того, и другого.

Это печально. async/await прямой путь к зашквару кода. Вирус от которого потом не излечишься.

Меня смущает не сам факт тайп хинтинга, а то, как это выглядит. Это не похоже на питон. До этого в питоне почти все писалось словами, а теперь появляются двоеточия, стрелочки, квадратные скобочки.

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

Такие ошибки можно детектить только на этапе функционального тестирования, и то если тесты достаточно хороши.

Другое дело это конпилятор.

Ну вот, опять все скатилось в стандартный срач static vs dynamic.

Толсто, но все же веселей чем static vs dynamic.

По сравнению с gevent это шаг назад. Вместо штуки которая просто работает, теперь предлагается руками выдрачивать модификаторы как и во всех остальных унылых async/await языках. Лично меня вполне устраивало что мультиплексирование случалось на io *автоматически* и вообще голова не болела об этом. Асинхронность, по сути, ни для чего больше и не нужна.

и вообще голова не болела об этом

то есть голова не болела — даже в ситуациях когда ты думал будто await НЕ случится, а оно всё-же случилось, и внезапное переключение на другую зелёную-нить разорвало целостность недоконца-изменённого состояния..? o_0

ох.. ну и дела! :-)

По сравнению с gevent это шаг назад. Вместо штуки которая просто работает, теперь предлагается руками выдрачивать модификаторы как и во всех остальных унылых async/await языках

ведь в gevent ты понятия не имеешь когда (в какой момент?) случится переключение.. и всё что можешь сделать для перестраховки — это накидать сверху синхронизирующих примитивов!

вызывая ту или иную функцию, ты же не знаешь, будет ли оно использовать io или нет %) %) .. или будет ли функция использовать io в своей будущей версии %) :-) ..

но.... хм... постоянно накидывать сверху синхронизирующих примитивов? это же намного больше гемороя чем пару раз *вручную* указать await где нужно :-)

и внезапное переключение на другую зелёную-нить разорвало целостность недоконца-изменённого состояния..?

async/await также рвут целостность, пусть и с ожиданным переключением.

и всё что можешь сделать для перестраховки — это накидать сверху синхронизирующих примитивов!

Всегда хватало стека без синхронизирующих примитивов и нормальной реализации context locals.

ведь в gevent ты понятия не имеешь когда (в какой момент?) случится переключение..

В этом и смысл, лично мне фиолетово когда оно случится, я же не мартышка для набивания async/await.

чем пару раз

Ню-ню.

> чем пару раз

Ню-ню.

ну ты понял смысл: пару раз — в каждой функции :-)

--------------------------------------------------

async/await также рвут целостность, пусть и с ожиданным переключением.

то что async/await рвут целостность с ожидаемым переключением — это не так интересно.

а главное же что — async/await НЕ рвут целостность в тех местах в которых ты НЕ ожидаешь переключения :-) ..

улавливаешь разницу между этими двумя предложениями? :-)

Это не похоже на питон. До этого в питоне почти все писалось словами, а теперь появляются двоеточия, стрелочки, квадратные скобочки.

Квадратные скобки в Python испокон веков, двоеточия для аннотаций и стрелочки - с Python 3.0.

а главное же что — async/await НЕ рвут целостность в тех местах в которых ты НЕ ожидаешь переключения :-)

Давай примеры в которых я не ожидаю переключения на io. Ну или примеры в которых неожиданное переключение мне что-то сломает.

> а главное же что — async/await НЕ рвут целостность в тех местах в которых ты НЕ ожидаешь переключения :-)

Давай примеры в которых я не ожидаю переключения на io. Ну или примеры в которых неожиданное переключение мне что-то сломает.

я тебе назвал ситуацию которая вполне может произойти, с определённой вероятность, с учётом фактора расстеивания памяти-программиста :) . это сложный случай, и нужна целая программа чтобы утверждать есть ли там такой феномен..

типично, если у тебя функция сначало инициализирует переменные, а затем делает какаие-то действия.

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

...а в момент инициализации переменных разрывов нет (так тебе кажется). :-)

но например инициализация переменных происходит через вызовы некоторых фунций (которые генерируют какието значения и используют текущее состояние)

и допустим эти функции неожиданно создают в некоторых случаях разрывы. а ты не мог это предположить (или же раньше они не создавали разрывов а потом начали создавать).. и выходит что переменные инициализировались таким образом что в савокупности они бирут данные из разных временных состояний.

короче давай твой код — я быть может найду там пару потенциальных ошибок :-) ..[«потенциальных» это значит сейчас всё работает норм, но при определённых условиях будет фэйл]

свой код показать, извини, не могу, так как я же не делаю ошибок (специально:))!

ну и даже если у тебя (в твоём коде) мы ошибок не найдём — то всё равно это не значит что gevent (в отличии от ручного await) имеет правильный подход...

...вдруг вообще окажется, что ты настолько гениально-умный(!), НАСТОЛЬКО, что даже используя gevent, ты всё-равно не делаешь ошибок :-) .

но ведь ты же не сможешь написать все программы в мире! поэтому нам нужна технология, которая позволяла бы не делать ошибок даже в ситуации отсутствия гениального ума :-)