Претензии хейтеров к Питону

начнете оплачивать

почему-то всегда когда оппонент сливается он начинает клянчить бабло

Да потому, что НЕЛЬЗЯ так делать. Если ты вызываешь асинхрон ты должен ГАРАНТИРОВАТЬ что никто не влезет туда. Вот тебе асинхрон.

async def f():
   token = await get_token()
   result = await call(token, 'tear_egg_rsync')
   await destroy(token)

ioloop = asyncio.get_event_loop()
tasks = [
    ioloop.create_task(f()),
    ioloop.create_task(f()),
    ioloop.create_task(f())
]
ioloop.run_until_complete(asyncio.wait(tasks))
ioloop.close()

Все. Ты отрубил себе....

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

Все. Ты отрубил себе....

дык об этом и речь: Python разрабатывают кретины

Если ты вызываешь асинхрон ты должен ГАРАНТИРОВАТЬ

еще раз.

если асинхронный код выполняет ровно одну нить/сопрограмму, то в этом случае он вырожден до синхронного.

от синхронного ничем не отличается.

соответственно писать библиотеки одновременно могущие использоваться и в асинхронном и синхронном применении - вполне возможно. И в других языках так и делают.

проблема Python состоит в том что разработчики-кретины наложили СЕМАНТИЧЕСКОЕ ограничение и в Python приходится разрабатывать совсем другую библиотеку для асинхрона. Соответственно перевести проект из синхрона в асинхрон без тотального переписывания нельзя.

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

состояние гонки к обсуждаемому вопросу не имеет никакого отношения.

если это не так, то покажи связь: при чем тут СЕМАНТИКА async/await и состояние гонки

1. Отступы и именно отступы - основная проблема этого языка. Любители копипастить код из тырнета не дадут соврать... А вообще, формировать блоки отступами - изначально гнилая идея, форматирование ведь иногда ломается.

2. GIL - а для кого это проблема? Для сисадминов, к примеру, GIL ни разу не проблема.

3. Отсутствие многострочных лямбд - существенный недостаток.

Ко всему прочему, у python есть такая беда как многословность. Один и то же код на python и ruby будет у второго выглядеть лаконичней.

1. Отступы и именно отступы - основная проблема этого языка. Любители копипастить код из тырнета не дадут соврать... А вообще, формировать блоки отступами - изначально гнилая идея, форматирование ведь иногда ломается.

помимо прочего форматирование кода отступами закрывает возможность написания некоторых видов программ: например шаблонизаторы с языком-embedded.

Например у Perl есть Mojo с его perl embedded у JS тоже есть embedded у PHP так оно изначально такой есть

а у Python нет. (есть одна попытка реализовать, но в этой попытке ввели операторы обозначения блока, то есть ушли от парадигмы python)

если это не так, то покажи связь: при чем тут СЕМАНТИКА async/await и состояние гонки

При том что сервер или СУБД могут быть конечными автоматами с сохранением состояния. И если 1 удалил токен, то у второго в момент отправки сообщения он ИСЧЕЗНЕТ.

Нельзя так делать. И уж если честно раз ты такой весь умный - напиши свой Python и проверим (ну а хвалить perl можесь сколько угодно, только разумные люди его уже бросили)

Отсутствие многострочных лямбд - существенный недостаток.

Никто так и не смог объяснить в чем недостаток...

примеров приводили множество. даже в этой ветке.

например мап-редюс чуть сложнее hello world уже невозможно писать на однострочных лямбдах.

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

При том что сервер или СУБД могут быть конечными автоматами с сохранением состояния

состояние гонки тут при чем? мы обсуждаем СЕМАНТИКУ языка.

множество других языков позволяет работать с корутинами. Вот например Lua вполне обходится без семантических ограничений.

https://www.lua.org/pil/9.1.html

несмотря на то что Lua тоже говноязык

Однострочная лямбда, при стандартной длине строки не более чем в 70 символов может быть только очень примитивной лямбдой. В ruby лямбда может быть по функционалу эквивалентна небольшой функции(многострочной, естественно).

например мап-редюс чуть сложнее hello world уже невозможно писать на однострочных лямбдах.

Объясни для тупого чем lambda x: отличается от def f(x)?

состояние гонки тут при чем? мы обсуждаем СЕМАНТИКУ языка.

При том, что ты должен ВИДЕТЬ что тут пошла асинхронщина.

Откуда ты знаешь в луа что под капотом?

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

Расскажите разницу между лямбдой и функцией. https://en.wikipedia.org/wiki/Lambda_calculus Lambda calculus (also written as λ-calculus) is a formal system in mathematical logic for expressing computation based on function abstraction

70 символов

Никто не мешает её писать в несколько строк. Дело не в этом, а в том что в лямбдах нельзя заводить переменные и нельзя их использовать как замыкания.

In [7]: lst = [lambda: i for i in range(3)]

In [8]: for f in lst:
   ...:     print(f())
   ...:
2
2
2

излишним оверхедом и задачей придумывать название функции

При том, что ты должен ВИДЕТЬ что тут пошла асинхронщина.

и вот это требование ВИДЕТЬ запрещает писать библиотеки, которые будут работать и в синхронной и в асинхронной среде.

об этом и речь.

именно это требование - и есть большой недостаток

Откуда ты знаешь в луа что под капотом?

ну во первых знаю (писал на Lua несколько лет, причем именно связку C/C++ <-> Lua), но речь же не об этом. речь о семантике.

Семантика корутин не требует обязательной разметки кода ключевыми словами. Пример многих языков - тому подтверждение

Расскажите разницу между лямбдой и функцией

лямбда == функция без имени.

в питоне нет лямбд. В питоне есть оператор lambda, который не есть полноценная функция.

Не читал ваш срач, но ты можешь дергать эти корутины с run_until_complete просто. В nodejs обычно есть функции типа get_results и get_results_sync. Ничто не мешает тебе сделать такую же _sync в питоне, которая будет просто делать run_until_complete

мы говорим о языке и его семантике.

язык предлагает два оператора: async/await.

причем второй - запретили семантически использовать без первого.

а то что извратнуться можно по всякому - с этим не спорит никто. гринтреды вон были же и во втором питоне.

во втором питоне корутины можно было писать без всякого async/await через yield. да и в 3-м можно

корутины писать без всякого async/await через yield

только нужно сильно стараться чтобы они стали совместимы с теми что написаны с async/await

Ах строгая типизация прям вот наш спаситель. В тоже время я видел сотни NullPointerException в Java, C# и прочих. А недавно неверные данные завалили целый кластер Go программ (а Python бы не упал...)

Я знал, что ты отбит, но не догадывался, что настолько. Ты серьёзно думаешь, что «не упал» и насрал куда-то «неверными данными» на 200% в таком случае лучше, чем «упал»?

В Нормальном ЯП сервак бы упал выдав дамп. А этот просто работал

Какая связь между яп и поведением конкретной реализации сервака? Я на чём угодно могу написать сервак, который будет просто работать и молчать.

в питоне разработчик опечатывается и пишет
self.foa = bar; # вместо self.foo = bar;
и этот замечтательный езык молча хавает (как и двойные определения def foo, затем def foo), а разработчик потом ищет ошибку самостоятельно. ППЦ

Так очевидно, что в языке с дт не надо так делать, а надо писать какую-то херню, которая будет тебе инжектить bar а self.foo, чекать есть ли у self foo и громко падать, если нет или если сделали двойной def. Вы требуете от языка с дт то же, что от статики. Зачем? Пишите на статике просто.

типизация тут ВООБЩЕ не при чем.

тут проблема движка ООП: способа задания атрибутов.

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

Ты серьёзно думаешь, что «не упал» и насрал куда-то «неверными данными» на 200% в таком случае лучше, чем «упал»?

Я думаю, что лучше не произвести банковскую транзакцию, чем провести ее неверно.

Я думаю, что лучше не произвести банковскую транзакцию, чем провести ее неверно.

Вот я тоже думаю, что этот твои питон лучше бы упал.

типизация тут ВООБЩЕ не при чем

Я согласен.

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

Да, именно это я и говорю. Просто не надо дёргать этот объект. Он будет private by design, а работает с ним только спецкод, который его проверяет, выдаёт объекты наружу и т.д. Если профита в таком подходе не видно, юзай нормальную статику.

Есть __slots__, есть датаклассы

У меня так было. Я написал программу передачи данных через ЦБ. Ее взял себе ФондСервисБанк. Клиент хотел отправить сумму превышающюю 2147483647 В итоге прога упала. Ребята обратились ко мне и я в течении часа исправил и деньги были перечислены следующим рейсом.

Я боюсь чтоб сделала ваша программа...

Датаклассы суть сахар. __slots__ зорошая штука, но в 2.6 я получил забавные баги. Хотя отсутствие __dict__ конечно добавляет скорости...

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

Сахар и чо? «язык никак не защищает ни от очепяток ни от повреждений внешними» - с frozen dataclass такой проблемы не будет, заодно его можно сеареализовать.

Это стандартные вещи из PEPов и стандартной библиотеки, я не знаю что такое «средний питонячий код». Еще namedtuple да. У них разное применение у всех. Я не вижу никакой кривизны в том что питон динамический язык и ты можешь добавлять аттрибуты инстансам по-дефолту, так и было задумано.

Я не вижу никакой кривизны

просто больших проектов не видели

Ну говорят, что их допилят до слотов и они будут быстрее...

define большой проект. в текущем у меня 896 python файлов и 69467 строк. Но были и больше.

слоты это скорее про потребление оперативки

И скорость до 18% выше. Там поиск уже не по dict....

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

Открытый всем ветрам инстанс это ахтунг. Сразу добавляет +100 к мощности выстрела в ногу. Чтобы спастись хотя бы от опечаток уже приходится костылять. Объект со слотами нельзя безопасно подставить вместо обычного объекта (ведь клиентский код может лезть в dict). Очередной частный случай на ровном месте. В общем от питона сплошные фейспалмы. Датаклассы когда появились то? Позавчера? Еще один фейспалм, как все эти годы без них жили.