Pull to refresh

Comments 62

Спасибо. Действительно, термин короткое замыкание является устоявшимся, исправил в статье.

Поскольку термин short circuit является метафорой, прямо отсылающей к "электрикам" — то и перевод можно использовать тот же самый.


А по вышей ссылке наблюдается явная нехватка источников.

"short-circuit evaluation" - "вычисление по короткой цепи" (досл.); не похоже что эта метафора так легко используется прямо и без адаптации. Как "КЗ" превратить в эти самые "вычисления" понять крайне затруднительно.

Я бы посмотрел перевод в документации M$ и подобных гигантов. У них есть гайдлайны для переводов, так что должно быть всегда одинаково. Там не всегда идеально (от перевода чекбокса я до сих пор подёргиваюсь), но велик шанс, что их перевод будет/станет общепринятым.

Вот документация от Microsoft — последнее место где надо искать правильный перевод. Они даже не пытаются сделать его правильно.

Дело не в правильности, а в шансах, что они продавят свой перевод и он станет общепринятым.

Опять про моржа...Кому как, но субъективно укорочение кода нередко приводит к его нечитабельности. Вопрос, надо ли приносить операторы из других языков для того, чтобы "стильно, модно, молодежно", с очень сомнительным выигрышем в производительности (он вообще есть..?), остается открытым и делом вкусовщины.

оператор Walrus

Уж или “моржовый оператор”, или “оператор :=”. Это google translate, что ли?

извините за офтоп, а почему сотрудник компании МойОфис кодит на питоне, а компания в продукт в качестве языка макросов воткнула ублюдочный LUA?

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

и что ж там неплохого? То, что делалось в VBA на 5 строчек стало 20?

Плюс IDE встроенный в мойофис абсолютно ублюдочный. Макрорекордер не только не помогает, но еще больше запутывает. Я понимаю, что у кого-то здесь реклама и я не в кассу со своими претензиями. Но доколе?

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

Плюс IDE встроенный в мойофис абсолютно ублюдочный

Если IDE плохая, то она будет такой и с питоном, и с lua

Сейчас нет нужды тащить его немаленький весь и целиком. Достаточно обеспечить базовый функционал

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

Да и того... у меня на ноуте терабайт

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

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

в VBA именно так относительно VB, и никаких проблем не было

Если IDE плохая, то она будет такой и с питоном, и с lua

IDE усиливает ублюдочность Lua

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

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

в VBA именно так относительно VB, и никаких проблем не было

Сомневаюсь, что из VB вообще можно было много урезать, а питон мы берём в частности и из-за его обширной стандартной библиотеки

ублюдочность Lua

О вкусах не спорят, все дела (но тогда и не стоит во второй раз упоминать "ублюдочность"), но, имхо, Луа нормально выглядит; может быть стоит убрать остатки паскаля в виде begin/end, но проще уж оставить стандартный Луа

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

Когда-то мне приходилось сидеть за нетбуком с двумя гигами рамы. Линукс работает нормально, винда - нет. Firefox работает неплохо, хром - нет. Все четверо - полноценные продукты, но некоторые работают на "печатной машинке", некоторые нет

Но даже не в этом дело - нет даже понимания собственной ущербности, и, соответственно, не видно желания как-то исправлять.

Пользовались "Мойофисом"? Я - нет, но я как-то и не слышал заявлений прямо об "ущербности" продукта. Да, недоработки есть, функционал неполный, но всё же, или вывод сделан только по причине использования Lua?

а питон мы берём в частности и из-за его обширной стандартной библиотеки

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

Lua не позволяет полноценно автоматизировать и закрывать отсутствующие функции. Повторяю, язык, в отличие от VBA не развит, объектная база скудная, стандартные библиотеки скудные. Прочитал инструкцию по Lua и охренел, потому что простое изменение шрифта в выделении превращается в квест.

Все четверо - полноценные продукты, но некоторые работают на "печатной машинке", некоторые нет

МойОфис не сильно экономит память и ресурсы, да. поменьше мелкософтов, но функционал тоже пропорционально меньше. Про полноценность я бы не говорил, потому что стандартных инструментов мало, и поддержки макросов фактически тоже нет: язык и IDE к пользователю недружелюбны по максимуму, а некоторые вещи вообще нереализуемы (по крайней мере, из того, что я прочитал). Какая мне разница, если я сильно теряю в функционале, переходя на него?

Пользовались "Мойофисом"? Я - нет, но я как-то и не слышал заявлений прямо об "ущербности" продукта.

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

по размеру стандартная библиотека не больше стандартной для VBA

я не спец в VBA, вы не спец в питоне, но я слышал как о с.б. питона отзываются как о [чуть ли не] мощнейшей среди всех языков вообще.

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

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

просто продекларировать, наличие при фактическом отсутствии

то есть для вас ни один встраиваемый язык кроме VBA за язык и не считается?

Lua не позволяет полноценно автоматизировать и закрывать отсутствующие функции. Повторяю, язык, в отличие от VBA не развит, объектная база скудная, стандартные библиотеки скудные.

Потому что это встраиваемый язык. Окружение должно предоставлятся программой

Прочитал инструкцию по Lua и охренел, потому что простое изменение шрифта в выделении превращается в квест.

Вопросы к авторам софта, не к Луа. И VBA можно в такое превратить, только майкрософт предоставили нормальное окружение, в отличие от авторов мойофиса. Условный доступ к ячейке или что угодно ещё для взаимодействия с продуктом - зона ответственности не Луа, а разработчиков этого самого продукта.

Про полноценность я бы не говорил, потому что стандартных инструментов мало, и поддержки макросов фактически тоже нет: язык и IDE к пользователю недружелюбны по максимуму, а некоторые вещи вообще нереализуемы (по крайней мере, из того, что я прочитал). Какая мне разница, если я сильно теряю в функционале, переходя на него?

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

Как бы нехилый вызов - переписать всю свою кучу примочек и костылей с VBA на Lua

С Lua на VBA не лучше

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

см. пункты про "окружение"

я не спец в VBA, вы не спец в питоне, но я слышал как о с.б. питона отзываются как о [чуть ли не] мощнейшей среди всех языков вообще.

у меня и то, и то на ноуте. По размерам ничего страшного. если бы вместо Lua взяли питон, например. Апелляция к размеру несостоятельна.

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

там, где требуется серьезный анализ данных, соотношение обратное. Да и откуда статистика-то? 2007 активно заменялся - прошло 15 лет. Я его даже когда фрилансил на VBA не видел ни разу.

Вопросы к авторам софта, не к Луа. 

зона ответственности не Луа, а разработчиков этого самого продукта.

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

Lua специфичен как внутренний язык для тех программ. где требуется КВАЛИФИЦИРОВАННАЯ ДОРАБОТКА ПОД ПОЛЬЗОВАТЕЛЯ. А в качестве языка массового пользования с низким порогом он абсолютно непригоден - все, вываливающееся за пределы куцего набора встроенных функций и операторов, выполняется через C API. Есть разница между - у меня замначальника склада с помощью макрорекордера, гугла и какой-то матери в экселе накропал форму для проверки инвентаризаций и я судорожно ищу, где бы мне нанять фрилансера, чтобы накропал на склад форму для проверки инвентаризаций, потому что мне некогда, а мужик никогда не разберется с этой хренью, особенно с API даже если его накачать амфетаминами для повышения работоспособности. Это безотносительно окружения

Опять история про окружение и суть встраиваемых языков. 

Нет, не только. И выбор Lua неудачен - таргет-группа его не примет - и реализация еще более ухудшает этот выбор.

С Lua на VBA не лучше

лучше и проще. Я с джаваскрипта как-то на VBA переписывал код. Никаких особых проблем не встретил, даже улучшил.

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

По размерам ничего страшного. если бы вместо Lua взяли питон, например.

мы не берём питон не только потому что он большой, а в том числе и из-за того, что из него многое придётся вырезать, и получится новый ЯП, вместо "везде-одинакого" стандартизированного питона

см. также вашу фразу: "Про питон. Сейчас нет нужды тащить его немаленький весь и целиком. Достаточно обеспечить базовый функционал и дальше подключить кастомные библиотеки "

вот я и задаю вопросы к авторам софта в первую очередь.

(дальше в этой паре абзацев, кстати, претензии опять к софту, а у нас спор про Python/Lua/VBA в разных комбинациях)

все, вываливающееся за пределы куцего набора встроенных функций и операторов, выполняется через C API

стало даже интересно, что такого не могут разработчики софта предоставить через стандартные функции Луа, что нужно аж тащить пробросы в C

лучше и проще. Я с джаваскрипта как-то на VBA переписывал код. Никаких особых проблем не встретил, даже улучшил.

если изначально написано плохо (в разной степени) то можно хоть на C переписывать и будет лучше

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

Спор начался с вашего утверждения что Луа - "ублюдочен" [по сравнению с VBA]. Ваши аргументы про ужасы написания программ для мойофиса не относятся к Луа, повторюсь, был бы VBA в мойофисе при такой же плохой реализации API самого офиса, было бы так же плохо.

Иван, добрый день, я веду направление исследований и UX, мне и моим коллегам из дизайн команды МойОфис было бы очень интересно поговорить про ваш опыт работы с макросами. Просто напишите мне в телеграм ulitin_kirill и запланируем звонок. Спасибо за неравнодушие!

есть куча питоноподобных аналогов. Тащить весь Питон не обязательно.

А есть Луа, как раз созданная для применения в данной сфере; создавать новый язык "не обязательно".

к какой он сфере, кроме садомазохизма применим?

"Lua не имеет встроенных отладочных средств. Взамен, он предлагает специальный интерфейс функций и перехватчиков (hook). Этот интерфейс позволяет строить различные типы отладчиков, профилировщиков и других инструментов, нуждающихся во "внутренней информации" интерпретатора. "

Это предлагается пользователю офисных приложений? Насколько далеки же были они от народа, что понесли это в массы!

А это "обычному пользователю" и не нужно. Ему нужно кататься по полям и строить циклы (или что там у вас); Уверен и VBA можно отлаживать с помощью паяльника, а "пользователь" такое вряд ли сможет применить даже чисто технически где-то в каких-то "моих офисах"

А это "обычному пользователю" и не нужно. Ему нужно кататься по полям и строить циклы (или что там у вас);

э-э-э... то есть, вы предлагаете вмето банального пошагового исполнения с промптом (как это реализовано в VBA) тестировать цикл через костыли специальных тестов? Как у меня один мужик писал макросы. Посмотрит в интернет, скопирует, ни хрена не понимая. Скопировал - смотрит, что получается на каждом шаге. Ошибка - меняет, параметры. Некорректные данные - меняет. Так и шел методом тыка. А в мойофис предлагается сразу начистовую писать загаженную лишним синтаксисом длинную строку строку и молиться, чтобы исполнилось. Вы сильно далеки от реальных требований пользователя малой автоматизации.

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

относятся еще как. При интуитивно понятной и просто организованной объектной модели и несложном синтаксисе пользователю работать проще в любом IDE. Но LUA не обладает этими качествами. Сам по себе синтаксис там существенно повышает порог вхождения пользователя в среду, а если еще и IDE кривой. то даже для меня, достаточно опытного человека. сожравшего не одного сенбернара на малой офисной автоматизации, вхождение представляет достаточные трудности, и добровольно без принуждения я этим не займусь. Что говорить о каком-нибудь библиотекаре, которой поставили это ваше "импортозамещение", и которая рада бы автоматизировать какую-то рутинную работу (которой масса), но вряд ли сможет даже понять, с чего начать.

Язык, он существует не в вакууме, и оценивается исключительно в комплексе. В данном случае при прочих равных это однозначно плохой выбор - узкое сообщество, плохо разработанная документация, нет учебников и курсов для слабо подготовленного пользователя, мало собственных библиотек (и, подозреваю, часть их написана на коленке), не наработан опыт использования. В итоге в выборе между Libre Office, МойОфис и P7 лично я склонен к первому.

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

А с синтаксисом-то что не так?

а что там так, если практически перед каждым оператором надо бессмысленный текст вставлять?

к вопросу, а что хорошего в нем? Хорошая документация, великолепные пособия. широкое сообщество? Интуитивно понятная объектная модель? Он даже к ячейке напрямую. как это VBA делает, не умеет обращаться.

Он даже к ячейке напрямую. как это VBA делает, не умеет обращаться.

Это проблема не языка, а биндингов

да мне пофигу. чья проблема. Повторюсь.

Пользователю абсолютно пофигу, чья проблема.

Фактом остается то, что в МойОфис воткнули язык, в котором встроенного обращения напрямую к ячейке нет, а биндингов не вкорячили.

Это нисколько не отменяет того, что разработчики - криворукие обезьянки. И не отменяет того, что Lua не приспосолблен для данного продукта.

Ну вот представьте, что в МойОфис вкорячили ещё и VBA. С точно таким же API, как и был в Lua (потому что по-другому не умеют или не хотят). Что, пользователю легче стало?

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

И где же существенное усложнение между, например,Sub Name() / End Sub и function name() / end, If / Then / End If и if / then / end , Dim i As Integer / For i = 2 To 10 / Next i и for i=2,10 do / end ?

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

Вряд ли в таком случае он лучше справится с VBA, не понимая его даже близко.

узкое сообщество, плохо разработанная документация, нет учебников и курсов для слабо подготовленного пользователя, мало собственных библиотек

И сообщество, и документация вполне себе, имхо. "Учебники и курсы" - первый же нагугленный туториал вполне себе может быть понят пользователем со средним уровнем владения ПК.

В итоге в выборе между Libre Office, МойОфис и P7 лично я склонен к первому.

А в либре, в свою очередь, VBA с майкрософтовским совместим не полнолностью. Вот у нас и два разных языка.

ИМХО, возможно будет проще загонять инфу в какой-нибудь питон

Как зато в питоне удобно будет "рядовому пользователю" катать данные по CSV файликам, да-а.

И где же существенное усложнение между, например,Sub Name() / End Sub и function name() / endIf / Then / End If и if / then / end , Dim i As Integer / For i = 2 To 10 / Next i и for i=2,10 do / end ?

там разница начинается. когда начинаешь работать с объектами. Давайте не юродствовать, все взрослые люди.

Вряд ли в таком случае он лучше справится с VBA, не понимая его даже близко.

VB много лет изучался в школе и в ВУЗах, по нему тонна учебников и толпа сообществ. QBasic, например, очень повально используется на курсах для детей младшего школьного возраста. По VBA куча УЖЕ ГОТОВЫХ скриптов в сети. Это как бы намекает. что разобраться будет гораздо проще. У нас даже в 1994 году в местной библиотеке у меня через дом была книжка по бейсику :) А вот по Lua я пока что нашел два очень маловразумительных описалова, ну. на английском есть кое-что, а сообществ, тем более под локальный продуктМойОфис, я в сети не видел.

Нагуглили вы туториал, и что? Эффективность внедрения языка в массы, так же, как и в естественных языках, определяется количеством и качеством носителей, характером СРЕДЫ. А среды языка нет, там все скудно - носитель с носителем в лесу аукаются.

Если компания решила "штурмовать небо", то есть пересадить население на Lua, очевидно. что нужны:

  • учебные программы

  • курсы

  • большое количество специальной литературы

  • библиотеки

  • огромная масса уже готовых скриптов

  • сообщества разработчиков и пользователей, эффективная обратная связь

  • постоянное развитие продукта как в плане IDE, так и объектной и функциональной модели

  • наконец, время для развития

Это целый большой и сложный комплекс мероприятий, и серьезные компании всячески стараются эти затраты минимизировать, взяв язык, где все это в массе своей уже есть. Вместо всего этого компания МойОфис решила, что выплывет на единственной доске от этой лодки - то есть, со временем оно как-то "само" разовьется. Такое впечатление, что изначально шел расчет на монопольное и безальтернативное внедрение через государственные структуры, а потому на пользователя, как в таких случах делается. банально насрали. .

там разница начинается. когда начинаешь работать с объектами. Давайте не юродствовать, все взрослые люди

А примеров от вас мы, кстати, так и не дождались.

QBasic, например, очень повально используется на курсах для детей младшего школьного возраста.

...И там же остаётся (и ещё, QBasic, BASIC, VB, VB.NET, VBA и прочие это всё-таки разные вещи).

У нас даже в 1994 году в местной библиотеке у меня через дом была книжка по бейсику :)

Хороший аргумент, для 1994 года. Сейчас есть языки современнее и лучше.

пересадить население на Lua

VBA не выйдет использовать, ибо он закрыт и несвободен; LibreOffice пытался, но вышел новый диалект, и вместо копирования скриптов приходится разбираться, а почему это программы на "одном языке" там работают, а тут нет, а Lua - чуть ли не единственный язык, как раз заточеный под встраивание и самый в этой сфере распространённый (VBA не считается ибо см. выше)

Такое впечатление, что изначально шел расчет на монопольное и безальтернативное внедрение через государственные структуры

Да. Поэтому, вероятно, и взяли "готовый" Луа вместо запила своего диалекта VBA.

Мы тут вроде бы спорили, хорош ли Луа как встраиваемый язык, а переезд на него с VBA к этому как-то не относится.

...И там же остаётся (и ещё, QBasic, BASIC, VB, VB.NET, VBA и прочие это всё-таки разные вещи)

не сильно разные

А примеров от вас мы, кстати, так и не дождались.

продолжаете юродивого косплеить? Покажите мне пользователя МойОфис, который без бэкграунда в программировании освоил Lua.

Хороший аргумент, для 1994 года. Сейчас есть языки современнее и лучше.

у вас, похоже, серьезные проблемы с восприятием информации. Я вам пишу не про ЛУЧШЕ, а про то. что порог вхождения в частности. зависит, от уровня распространения языка, учебных пособий, количества носителей, среды и пр. Бейсик массово ставили на школьные машины как раз тогда, когда современные люди среднего возраста в школе обучались, были выпущены тонны литературы. Это плюс к тому, что пользователь легче его освоит. А "лучше" для малоквалифицированного пользователя абсолютно непринципиально. Навпример, VBA не позволяет полноценное наследование классов. Возможно, ваш Lua позволяет. И что? 98% пользователей VBA о классах вообще не имеют даже подозрения. а 99% ими не пользовались никогда.

Нельзя ЯП рассматривать в вакууме, вне СОЦИАЛЬНОЙ СРЕДЫ. А вы именно это пытаетесь делать

Вопрос в том, зачем было тащить туда хоть что, отличное от VBA. В существующих офисных файлах скрипт - это VBA, зачем надо было выделываться и городить свой велосипед? Мотивации так делать я в упор не понимаю.

Как бы потому что VBA принадлежит Майкрософту и он не будет счастлив, если кто-то сделает ABV, который будет похож на оригинал до степени смешения.

Sublime Text размеры Питона как-то не помешали

Потому что lua подключить проще (сам подключал, тоже некоторые пользователи плюются).

И вообще, ценность python как встраиваемого языка преувеличена. Он распространён (его знает уйма закончивших курсы людей), много библиотек; и на этом всё. А в остальном lua не хуже как встраиваемый язык.

Он распространён (его знает уйма закончивших курсы людей), много библиотек; и на этом всё.

Так в этом и есть основная ценность и преимущество Питона, в том числе и как встраиваемого языка.

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

Я же занимался обучением людей в эксельку не один год. Ну не тянет пользователь без готовых шаблонов ничего самостоятельно. StackOverflow переполнен детских вопросов по VBA - там даже минимального понимания не просматривается у большинства. Ему и Basic, который полстраны изучало в школе, в форме VBA не заходит. Ему не заходят даже банально формулы (половина офисных хомячков имеют экселевский файл с готовыми формулами, потому что не понимают, как они работают и их синтаксиса, соответственно, потеряется файл- работу делать не могут. Один мужик как-то потерял свой файл с формулами - работа на участке встала, полдня не могли сформировать реестр, так как не смог подтянуть влукапом суммы, потому что никогда не знал формулу, добавляющую нолик по условию). А ему хотят предложить новый язык. по которому даже толкового пособия нет, и примеры кода посмотреть негде. Плюнет, развернется и уйдет.

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

Экономия 1 строчки кода с одной стороны, ухудшение читабельности с другой стороны. имхо, оно того не стоит.

это функциональность, которая появилась в Python недавно, в версии 3.8
Питону 3.8 уже три года, а актуальная версия 3.10.

Причём в обеих статьях ссылки на источник совпадают вплоть до символа. @Boomburum, есть ли в планах детектор таких клонов? :)

Я уже к прошлой статье такой комментарий писал:) Разработчикам языка следовало бы использовать := для ОБЪЯВЛЕНИЯ переменных, а = для присваивания УЖЕ СУЩЕСТВУЮЩИМ переменным (как в Go). Такой подход значительно обезопасил бы код от опечаток в именах переменных (когда вместо присваивания существующей переменной происходит создание новой).

А сейчас получается нечто странное:

x1 = 1        # ok
x2 := 2       # error
x3 = (y3 := 3) # ok
x4 = (y4 = 4)  # error

Т.е. один оператор работает только вне скобок, другой только в скобках. Причем возможно и вот такое

c = (d:=1)*(d:=2)

Какой в этом смысл? Не проще ли было просто разрешить обычный оператор = внутри выражений?

для присваивания УЖЕ СУЩЕСТВУЮЩИМ

В питоне нельзя толком проверить, существует переменная или нет. В любой момент ее можно подсунуть через globals.

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

Соответственно, нет ничего проще: операция "=" могла бы проверять наличие имени в словаре, и если имени нет - ошибка, если есть - обращение к значению. Операция ":=" аналогично могла бы проверять наличие имени в словаре, но ошибка генерируется если такое имя есть. Если имени нет, то добавлять в словарь имя и значение.

Как именно то или иное имя попало в словарь - совершенно неважно.

Получилась бы сомнительная польза в ущерб производительности. Словарь в Python'е одна из самых проблемных и медленных сущностей, но на ней держится вся логика переменных. Каждая такая проверка замедлила бы код минимум процентов на 20-30%.

Единственный вариант, как я вижу, если и делать такую проверку, то с помощью mypy. Но кмк это просто никому не нужно, поэтому никто и не делает. Да и, опять же, кмк это только усложнило бы читабельность.

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

Вы предлагаете дважды делать эту проверку или реализовать функционал, при котором в словаре можно будет бросать исключение при наличии ключа?

В любом случае это нафиг никому не нужно, поэтому никто не хочет усложнять код и синтаксис. Единственное, где это могло бы пригодиться - mypy. Но и тут это не нужно никому видимо.

Кстати, := — это не изобретение Вирта. Это ещё в ALGOL было, по образу которого во многом и создавался Pascal. Впрочем, в ALGOL много чего было. Например, сопрограммы.

Вы можете сказать "Просто добавь y = func(x) перед объявлением списка и тебе не понадобится оператор walrus!". Можно так сделать, но для этого потребуется еще одна дополнительная строка кода и, на первый взгляд, без знания о том, что func(x) очень медленная, может быть неясно, зачем эта переменная нужна.

Решил разрезать на две части:

но для этого потребуется еще одна дополнительная строка кода

А что в этом плохого? У вас буквы платные? Читабельность это главное! Не надо делать так, как в первом примере!

и, на первый взгляд, без знания о том, что func(x) очень медленная, может быть неясно, зачем эта переменная нужна

Как зачем??? Чтобы не вызывать 3 раза одну и ту же функцию! Это любой начинающий прогер сам догадается. Вызовы ведь вообще не бесплатные!

Так-то в Python есть ещё и кэши самых разных сортов. Закэшируй func(x) и вычислится она ровно один раз. Профит! (это как дополнение к комментарию)

Ваши специальные кэши никому не нужны. Самый оптимальный кэш - y = func(x) .

Мне нравятся некоторые примеры. С f-стринг, например. Но первый пункт не очень. Если там такая медленная функция, то проще с этим бороться в самой функции на не в местах её использования. Взять декоратор кеширования из functools, например.

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

Альтернатива reduce в две строки:

result = your_array[0] 
[result := your_func(result, x) for x in your_array[1:]]

Sign up to leave a comment.