- 1
- 2
- 3
- 4
XRU = "XRU"
PITUH = "PITUH",
KUROCHKA = "KUROCHKA"
PETUH = PITUH.replace('I', 'E')-
Python / Говнокод #27277
0
Traceback (most recent call last):
File "./prog.py", line 4, in <module>
AttributeError: 'tuple' object has no attribute 'replace'Запостил:
3_dar,
02 Марта 2021
Follow us!
О чем Гвидо говорил, они не понимали!
Мутабельные вещи ключами стрёмно пихать т.к. инварианты дерева могут рассыпаться.
Ну и для разврата нескольких значений из функции. Возможно, это немного эффективнее чем лист.
так сделали бы frozen list, нафиг сущность заводить?
>Ну и для разврата нескольких значений из функции.
типа как pair?
опять таки, почему не frozen list?
>эффективнее
в скриптушне разве я должен про это думать?
знаеш такую хуйню в JS
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze
?
Это ведь то же самое, что и (a . b . c) ?
И вообще мой пример в питоньем синтаксисе.
Надо освежить память. Но лень...
https://docs.racket-lang.org/guide/Pairs__Lists__and_Racket_Syntax.html
Тупл это обычная математическая питушня, а Гвидо был тем ещё ма-те-ма-ти-ком.
Кроме того, он сам по себе отличается от листа. У тупла даже размер меньше чем у списка.
> Эффективнее
В одной ОС для домохозяек не подумали об эффективности, и рабочий стол там сортирует иконки суперпузырьком )))
>эффективности
скриптоговно без JITа где каждый питух работает по ссылке это конечно офигенно эффективно, именно замена листа на тупл нас всех спасет)
Фиксированный набор значений определённой длины. Зачем ему быть изменяемым? Если ты изменил значение, то, очевидно, это уже другой набор. Не изменяй.
> зачем вообще такая питушня?
Она эффективнее, она удобная для своих кейсов каких-то. С помощью неё можно писать на питоне в функциональном стиле, который тебе так нравится.
> скриптоговно без JITа
Скриптоговно с JITом, конечно, будет сильно эффективнее. Если программист – кодер. А вот настоящий программист критические места перепишет на сишку, либо использует модуль, который подключает сишку. Потому что JIT – это полумера.
> замена листа на тупл нас всех спасет
Это капля в море. Но нельзя забывать, что море состоит из множества капель.
В нём не знаю, зачем отдельно
В Lua, к примеру, это просто специальный синтаксис. Никакие туплы там не создаются и не возвращаются, просто на стек пушится несколько результатов.
Кроме того, что это не помешало златохую уйти из программирования
З.Ы. Можно и все в таблицу захватить: t = {test()}
В питоне можно так:
b = test()[1]
Сохранит конечно... Боишься, что память потечёт?
_ = nil
не?
А мультиразврат -- это просто всякие мелочи в духе key/value, error/result и т.п.
Я к тому, что вот допустим мне нужно вернуть пять значений. Очевидно, лучше венуть таблу с нормальными ключами.
А два можно и через запятую.
В питоне есть тупла о девяти числах для представления времени, и конечно за такое нужно гореть в аду
вот тут мы приняли значение, а, оказывается, могли два. а может даже и три! скриптуха такая скриптуха
как это можно сравнивать с семантикой кортежей, вообще не представляю, сосёт же
Ну вернут тебе кортеж в питоне, и откуда ты знаешь сколько там членов, какой у них смысл, и вообще что тебе вернули кортеж?
мне любая скриптуха в достаточной мере противна именно поэтому
Но мы же сравнивали кортеж в питоне изначально с мультивозвратом в луа.
В чем разница?
Зачем вообще кортежи в скриптушне? Почему не возващать стурктуры/объекты как в JS или lua, или не делать вот мультвозврат?
Вообще чем меньше типов данных в СКРИПТУШНЕ - тем лучше. Потому что тем она проще. А перформанс это не про скриптушню.
В питоне очень много типов, куда больше, чем нужно.
А в луа их вроде всего 3
Ты ещё кресты поругай за struct / class )))
А ещё можно сделать скриптушню с ASM синтаксисом. Там вообще не будет типов данных!
мне проще запомнить имя поля, чего его порядковый номер, не?
скриптушня должна иметь структурную або утиную тупизацию, не требовать явного создания объекта:
return {
foo: 12,
buz:14
}
return ({
"foo" : 12,
"bar" : 14
})
ну и нахуй нам тупол тадада?
forth?
какие типы есть в shell?
* для пифоманса
* для статического анализа кода
Если ничего этого тебе не нужно, то и типы плодить не нужно.
https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy
Он очень хорошо объяснил зачем нужно скриптоговно, и почему из скриптоговна не нужно делать серьезный язык
сейчас динамически типизированный js выигрывает от мономорфизации по пирформансу и его можно интероперировать с типизированным тс или пихнуть в микросервис и работать по протоколу, да и сам по себе он типизируется аннотациями
по-моему сейчас единственное что имеет знаение при выборе языка - это используется ли он сейчас в экосистеме и знает ли его команда
пытаться управлять сложностью с помощью выбора языка это 90е какие-то
да и разница между компиляцией и интерпретацией сейчас размылась из-за jit
Чтобы понять, что это не так, достаточно мысленно сравнить работу с целыми числами в С++ и в JS, где они представлены как floating point.
Или вспомнить сколько тактов процессора занимает удаление стурктуры со стека (изменение значения указателя на стек) и удаление объекта из кучи через GC.
>да и разница между компиляцией и интерпретацией сейчас размылась из-за jit
А это правда, хотя JIT есть далеко не в любой скриптухе.
js выигрывает не у плюсов а у чисто интерпретированного js
я хочу сказать что когда формулировали дихотомию, были условно компилируемые языки типа джавы которая конпилируется и на которой хуй что опишешь меньше чем тысячей строк и условно интерпретируемый tcl который страшно медленный и без типов но на котором опишешь что угодно
сейчас картина сильно изменилась
Я согласен, что ситуация изменилась , и границы размылись, но на это размытие была потрачена уйма времени.
Люди начали писать большие сложные системы на япах, для них не предназначенных, и начали вдруг ахуевать от неудобств, и теперь завозят тайпхинты в питон, компиляторы TS в JS, и прочие KittensPHP.
Если бы скриптушня изначально использовалась только для написания скрипта рассылки почты, то и проблем бы таких не было.
в 2000 нельзя было сказать "парни, попуститесь, всего через 11 лет будет прекрасный язык котлин", пришлось писать на питоне или на джаве, что заняло бы в несколько раз больше времени
и это привело нас к тайпхинтам и hack
> пришлось писать на
пятом перле:)
зачем тебе скриптушня?
В общем наша с Остерхаутом мысля в том, что скриптушня нужна чтобы писать небольшие тупые скрипты.
Потому там не должно быть много структур, не должно быть стат типизации, и прочих сложностей.
Хочешь серьезного программирования -- бери другой изык.
И мне всегда немного смешно, когда питонобляди выбирают там взять кортеж или словарь , и говорят "кортеж быстрее" или "а зато для словаря у нас есть typed dicts, и мы можем статически проверить тип поля"
Если вас все это ебет, то нахуй вам скриптушня-то
https://medium.com/@jacktator/dataclass-vs-namedtuple-vs-object-for-performance-optimization-in-python-691e234253b9
> It is for this reason, majority of Financial Trading systems are written in C, C++, Python or Java.
Он идиот?
Обычные объекты в Python содержат внутри себя словарь '__dict__', который хранит все свойства инстанса. Это позволяет, няпример, добавлять свойства динямически:
За это, как ты понимаешь, приходится платить медленным доступом (каждый доступ к атрибуту — это поиск в словаре), и приличным увеличением потребления памяти: словарь, приклеивающийся к каждому инстансу, это тяжело.
__slots__ же ограничивает возможные атрибуты инстанса, сильно экономя память и прилично (по няпроверенным данным — ня 15-30%) ускоряя доступ к свойствам. За это приходится платить нявозможностью добавлять свойства в динямике:
Также, что очевидня, свойства '__dict__' у слот-машиныобъектов ня создаётся.
Вообшще полезная книжка, и спиздить её легко: она много где валяется
А если серьёзно, то ты прав, да. Что угодно можно написать на крестах, там есть все инструменты для удобного питушения.
Питон лично я использую только для скриптов вида «скролль эту страничку, потом сохрани её, чтобы другой скрипт распарсил её рагуляркой» и всякие сайтики.
Я думаю, что уровень питона как ЯП более чем достаточен, чтобы писать бизнес-логику и всякие формочки, а вот для всяких сложных вычислений всегда можно дописать модуль на крестах, с типизацией, пирфомансом... Как-то так.
бизнес логику кстати вполне приятно писать на стат типизированных языках
Для меня на данный момент самый прикольный ЯП, на котором ещё и заработать можно – это С++.
На втором месте питон с его возможностями в вебдеве.
c# лишен недостатков jvm
на нем можно писать и логику, и веб)
С одной стороны, мне вроде бы как нравится. С другой стороны:
Также опубликован пятый предварительный выпуск открытой платформы .NET Core 3.0, функциональность которой приближена к .NET Framework 4.8 благодаря включению в состав открытых в прошлом году компонентов Windows Forms, WPF и Entity Framework 6.
А если бы не захотели открывать, то что, лапу сосать? Такое мне не по нраву, не люблю Vendor Lock.
В принципе, кресты меня более чем устраивают, когда я пишу что-нибудь сурьёзное. Они с питоном друг друга хорошо дополняют :)
Кресты это отлично, но для написания логики это немного экстрим. Впрочем, ничего суперстрашного в том тоже нет
Что же произошло? Не такой большой промежуток времени, чтобы всё осознать (или я слишком стар стал, и у меня мало что меняется).
Тут вообще багор. Раньше «JRE» и «JDK» можно было просто так скачать. Теперь там нужно указывать е-мейл, чтобы получить ссылку для скачивания. Если е-мейл принадлежит организации, «Оракл» её завалит письмами с предложениями купить «JRE».
Ну или можно скачать «OpenJDK» без регистрации, о чём не все знают.
Ну дык, энтерпрайзный продукт...
В конце-концов, конечный юзер обычно получает джаву вместе с дистрибутивом софта на ней.
https://blog.joda.org/2018/09/do-not-fall-into-oracles-java-11-trap.html
Эм, разве JDK/JRE не с рождения были сраным проприетарным нешвабодным говном? Что там так неожиданно могло поменяться?
- надо читать не trap, а part
Вероятно, это на испанском.
Фиг знает, где они там ловушку нашли... Oracle даже предупреждение перед загрузкой показывает и предлагает купить полную версию или юзать OpenJDK.
Вполне. Этот мультиразврат обычно юзают в каких-то технических моментах в духе итераторов (key, value) или обработки ошибок (result, error).
и без ненужной сущности