Как единственный пока (?) пользователь зелёных в опросе отпишусь, что ВК в Сбере не настолько уж плох. Про Upwork они ничего не знают, к сожалению, но если самому зарегистривать двуязычный User Agreement в качестве контракта, то потом при последующих выплатах можно на него ссылаться. Только нужно следить, чтобы общая сумма по контракту не превысила 6кк рублей, т.к. после этого придётся ещё и счета-фактуры предоставлять. Но я это решаю путём перерегистрации свежей версии User Agreement.
Деньги при этом вывожу пока все через Payoneer, т.к. у них наиболее выгодный курс обмена в рубли.
Насчёт потребления памяти к dataclasses в их нынешнем виде есть много претензий. NamedTuple они в этом по-прежнему уступают.
Проблему можно обойти, если использовать дополнительную обёртку вроде этой. Но какой смысл было так торопиться, чтобы непременно зарелизить эти dataclasses во чтобы то не стало в 3.7 без предварительного решения такого ключевого вопроса, как встроенная поддержка slots — от меня ускользает.
Из личного опыта, мои сервера на Python все живут в микросервисных облачных платформах сейчас.
В случае с AWS Lambda миграция с Python 2 на 3 прошла хоть и не без приключений, но относительно быстро — разве что средство развёртывания пришлось сменить и доработать.
А вот с AppEngine SE переход оказался очень болезненным — многие привычные библиотеки и службы от Гугла просто перестали поддерживаться или безбожно глючат и тормозят.
В итоге миграция Питона с 2 на 3 часто выливается ещё и в дорогостоящее, навязанное извне технологическое перевооружение, причем не приводящее к какому-то заметному улучшению качества жизни пока что.
отсюда и появляются идеи насчет того… asyncio пришлось добавлять в язык из-за GIL
Мой комментарий был совсем не об этом. Видимо я недостаточно распространённо высказался из-за чего могло так показаться.
Контест следующий:
Изначально, ещё до всякого появления asyncio в экосистеме питона уже была (и есть) приличная и удобная возможность запускать "зелёные потоки": gevent.
Раздавались предложения её стандартизовать, но были отвергнуты, видимо потому, что там переключение происходит слишком неявно, а это не "Python Way".
Вместо этого Гвидо, никого не спрашивая решил, что сможет нас всех осчастливить реализацией некоего аналога .NET-овского async/await вообще без каких-либо дополнительных изменений в ядре интепретатора. Вся работа строилась на основе только что появившейся в Python 3.3 конструкции yield from.
Так в Python 3.4 появился asyncio (PEP 3156). Многие были не очень-то довольны волюнтаризмом Гвидо при продвижении (почти без обсуждения) столь значимой библиотеки в язык. Но раз уж это была просто ещё один пакетик в python/lib, поворчали и смирились — одним больше, одним меньше.
Уже после этого кавалерийского релиза выяснилось, что не всё так просто и без серьёзных дополнений в ядро интерпретатора asyncio практически бесполезен.
А раз уж он теперь часть стандартной библиотеки — не выбрасывать же. Коготок увяз — всей птичке хана :) Так в Python 3.5 пришлось срочно имплементировать настоящие корутины (см. PEP 432).
И вот я думаю. А что если бы этот ныне открываемый PyInterpreterState (а особенно его более мелкие части вроде PyFrameObject) были с самого начала доступны нам для базового манипулирования? Не вышло бы тогда, что и вся вышеперечисленная неприятная эпопея не понадобилась бы? А все желащние реализовывать зелёные потоки могли бы делать это на чистом Питоне и не париться.
Никакого особо развитых API для этого не нужно ведь, просто возможность сохранить указатель на текущий (хранящийся в куче) стек питоновских вызовов, передать/сохранить её куда нужно и переключить поток управления между этими фреймами на время ожидания сигнала.
Добавление в язык реальной многопоточности путём вытаскивания на свет интерпретатора, как сущности первого класса, с которой теперь можно реально работать и взаимодействовать — это отличное инженерное решение. Мне нравится.
Смущает только, зачем называть их "interpreters"? Для рядовых программистов, если думать о будущем развитии и экспансии языка, гораздо понятнее было бы вывести эту сущность как "worker" (а ля ECMAScript) или нечто подобное.
Ну, и вообще если подумать, раз уж был выставлен на всеобщее обозрение PyInterpreterState, почему бы не задуматься о добавлении возможности поманипулировать "снаружи" и его составными частями вроде PyFrameObject, с возможностью попереключать текущий контекст, стек и пр.
Думаю, что если бы нечто подобное было реализовано с самого начала, то и никакая эпопея с asyncio не понадобилась. А gevent был бы простенькой pure-Python библиотечкой без сишных хаков...
Вместо ручного разбора содержимого пакетов, удобнее воспользоваться ctypes или готовой библиотекой вроде dpkt или Scapy.
Ну а для файла конфигураций в Питоне удобнее и естественее использовать JSON или просто модуль config.py, вместо XML.
Известно что. "Авито" продалось подешевке нужному человеку, так что надобность в угрозе обнуления прибылей отпала.
Главная выгода от снижения расхода антибиотиков не в том, что они "гадость", а снижение скорости набора резистентности к ним у бактерий.
Как единственный пока (?) пользователь зелёных в опросе отпишусь, что ВК в Сбере не настолько уж плох. Про Upwork они ничего не знают, к сожалению, но если самому зарегистривать двуязычный User Agreement в качестве контракта, то потом при последующих выплатах можно на него ссылаться. Только нужно следить, чтобы общая сумма по контракту не превысила 6кк рублей, т.к. после этого придётся ещё и счета-фактуры предоставлять. Но я это решаю путём перерегистрации свежей версии User Agreement.
Деньги при этом вывожу пока все через Payoneer, т.к. у них наиболее выгодный курс обмена в рубли.
Насчёт потребления памяти к dataclasses в их нынешнем виде есть много претензий. NamedTuple они в этом по-прежнему уступают.
Проблему можно обойти, если использовать дополнительную обёртку вроде этой. Но какой смысл было так торопиться, чтобы непременно зарелизить эти
dataclassesво чтобы то не стало в 3.7 без предварительного решения такого ключевого вопроса, как встроенная поддержка slots — от меня ускользает.Из личного опыта, мои сервера на Python все живут в микросервисных облачных платформах сейчас.
В случае с AWS Lambda миграция с Python 2 на 3 прошла хоть и не без приключений, но относительно быстро — разве что средство развёртывания пришлось сменить и доработать.
А вот с AppEngine SE переход оказался очень болезненным — многие привычные библиотеки и службы от Гугла просто перестали поддерживаться или безбожно глючат и тормозят.
В итоге миграция Питона с 2 на 3 часто выливается ещё и в дорогостоящее, навязанное извне технологическое перевооружение, причем не приводящее к какому-то заметному улучшению качества жизни пока что.
Мой комментарий был совсем не об этом. Видимо я недостаточно распространённо высказался из-за чего могло так показаться.
Контест следующий:
asyncioв экосистеме питона уже была (и есть) приличная и удобная возможность запускать "зелёные потоки":gevent.yield from.asyncio(PEP 3156). Многие были не очень-то довольны волюнтаризмом Гвидо при продвижении (почти без обсуждения) столь значимой библиотеки в язык. Но раз уж это была просто ещё один пакетик вpython/lib, поворчали и смирились — одним больше, одним меньше.asyncioпрактически бесполезен.А раз уж он теперь часть стандартной библиотеки — не выбрасывать же. Коготок увяз — всей птичке хана :) Так в Python 3.5 пришлось срочно имплементировать настоящие корутины (см. PEP 432).
И вот я думаю. А что если бы этот ныне открываемый
PyInterpreterState(а особенно его более мелкие части вродеPyFrameObject) были с самого начала доступны нам для базового манипулирования? Не вышло бы тогда, что и вся вышеперечисленная неприятная эпопея не понадобилась бы? А все желащние реализовывать зелёные потоки могли бы делать это на чистом Питоне и не париться.Никакого особо развитых API для этого не нужно ведь, просто возможность сохранить указатель на текущий (хранящийся в куче) стек питоновских вызовов, передать/сохранить её куда нужно и переключить поток управления между этими фреймами на время ожидания сигнала.
Добавление в язык реальной многопоточности путём вытаскивания на свет интерпретатора, как сущности первого класса, с которой теперь можно реально работать и взаимодействовать — это отличное инженерное решение. Мне нравится.
Смущает только, зачем называть их "interpreters"? Для рядовых программистов, если думать о будущем развитии и экспансии языка, гораздо понятнее было бы вывести эту сущность как "worker" (а ля ECMAScript) или нечто подобное.
Ну, и вообще если подумать, раз уж был выставлен на всеобщее обозрение
PyInterpreterState, почему бы не задуматься о добавлении возможности поманипулировать "снаружи" и его составными частями вродеPyFrameObject, с возможностью попереключать текущий контекст, стек и пр.Думаю, что если бы нечто подобное было реализовано с самого начала, то и никакая эпопея с
asyncioне понадобилась. Аgeventбыл бы простенькой pure-Python библиотечкой без сишных хаков...Ну а для файла конфигураций в Питоне удобнее и естественее использовать JSON или просто модуль config.py, вместо XML.