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

Вот сейчас уже почти незаметны, потому и везде он теперь есть. А тогда - было заметно. Первая версия юникода - 1991 год, но поскольку потом были обратно-несовместимые изменения, пусть будет бетой. Вторая (2.0) - вобщем-то без существенных изменений дошла до наших дней - опубликована в 1996 году. В те времена у многих ещё были 16-битные компы, а данные передавались на дискетах (и вовсе не 1.44Мб объёмом). Если бы ты предложил ради каких-то технических изысков «а давайте толстая книга на русском (500 страниц по 2000 букв) будет теперь влезать не на одну дискету а на две» - тебя бы гарантированно не поняли. Аналогично, позже, тебя бы не поняли диал-ап клиенты интернета, ту же книгу желающие скачать. Или уже даже не книгу: открываешь ты страницу форума 50кбайт, 15 секунд, а потом умник вроде тебя решил перейти на прогрессивный утф-8, и страница стала открываться 30 секунд (про gzip опустим, он конечно сгладит разницу, но далеко не до конца, да и его тогда почти нигде не было). Или ещё современнее: дискеты не в ходу, инет уже у всех (почти) быстрый, а ты - владелец сайта с кучей текстового контента (пусть тот же форум), база форума занимает 30гб и влезает на запредельно дорогой прогрессивный ssd объёмом 40гб. Твой админ тебе рекомендует идти в ногу со временем и перейти на утф-8, купив для этого ещё один ssd объёмом 80гб. Потратишься? Кроме того, база внезапно начнёт жрать удвоенное количество памяти и процессорного времени, их тоже придётся докупать.

Зато неудобства серьёзные. Да, англичанам и европейцам это не нужно,

О чём и речь.

но всех остальных, кому нужно, в несколько раз больше.

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

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

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

Знать какие бывают кодировки, уметь на вид определить кодировку, уметь перекодировать любой файл,

Есть четыре кодировки: дефолтная IBM с закорючками вместо русских букв, дос 866, винда 1251 и koi8 на странных сайтах в инете. Закорючки сложно с чем-то спутать, koi8 отличается перевёрнутым регистром букв, ну а остальные две могут быть спутаны только друг с другом и вариантов не оставляют. По-моему, всё просто.

когда веб-сайт отдаёт одну неправильную кодировку, а браузер определяет как другую неправильную,

Сейчас такое тоже бывает. Чинилось и тогда и сейчас одинаково - копированием контента в файл и ручным перекодированием.

Никто, думаю, не хочет возвращаться в это время.

Я недавно попытался узнать, как же определить, на сколько символов вправо сдвинется курсор при выводе определённой утф-8 строки. Обнаружил, что единственный способ - это ДЕТАЛЬНО парсить всю строку. Нет, просто сконвертировать utf-8 в массив юникодных индексов (назовём utf-32) и посчитать их - недостаточно, потому что юникодный «символ» по факту может оказаться не символом а не пойми чем, влиять на соседей и не знаю что там ещё. Хуже того, нет нормального алгоритма даже для того, чтобы отфильтровать и выкинуть из строки всё сомнительное - это можно сделать только имея в памяти базу свойств юникодных сущностей (которая весит несколько мбайт). Рад ли я этому? Пожалуй, нет, лучше была бы 8-битная кодировка где я точно знал бы, что 1 байт = 1 символ во всех смыслах этого слова, за исключением, возможно, 00-1F и иногда 80-9F. Но поскольку теперь везде юникод, софт, работающий с текстом и не поддерживающий юникод окажется бесполезным, и приходится поддерживать его.

даже тип переменной никак не контролируется

>>> 1 + '2'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Java даже не ругнется на такое. Динамическая типизация != автоматическая конвертация типовю Мы всего лишь можем присвоить переменной новое значение с типом отличным от того с которым она была объявлена. Ок. А C++/Java - это языки со слабой типизаций, где есть автоконвертация.

Но зачем его контролировать? Не говоря уже о том, что последняя мода позволяет в попсе эти типы не указывать пихая везде auto, var…

Смысл был другой: японский ничем не хуже русского просто из-за различий в построении языковых конструкций не только красота стихов Пушкина никогда не станет понятной японцам, но это верно и наоборот - для нас хайку, извините, но просто какая-то херня из набора слов. Даже баш не настолько убог чтобы его выпилили как язык по-умолчанию для ракушки… иначе бы мы писали в терминале на чем-то типа виндового Power Shell, но со столь любимым тобой джавовым синтаксисом (точнее сишным)

Почему во многих Питон-проектах не используют async/await и ООП, как в Java?

Python конечно популярен, а я на нем даже «Hello World» не написал …

Это проверка типа значения в рантайме, а не переменной статически.

В Java - в принципе, нельзя так объявить даже 1 + ‘2’.

Придется объявлять переменные в классе, аля так (как и складывать «в твоем понимании»):

class Foo {
    private int _a = 1;
    private Character _b = 'c';

    public Character testAddition() {
        var result = _a + _b;
        System.out.println(result);
        return result;
    }
}

P.S. да, «var» появился в Java с версии 10. Стало аля, как в C#.

tz4678 ★★ (20.11.21 21:17:39)

Java даже не ругнется на такое…

Во-первых, ты тут получишь ошибку на этапе компиляции только:

Incompatible types. Found: ‘int’, required: ‘java.lang.Character’

Во-вторых, тебе нужно было для более жирного примера для наброса говна на вентилятор взять string-тип, а не char-тип. Тогда бы скомпилировалось и немного по-солиднее было бы для наброса в ЛОР… Но, опять же… Ты не учел один момент. Что спутал мягкое с теплым. Твой пример с Python - нерелевантен с Java, ибо:

Когда в Java, ты «типа» складываешь строку и целое число вместе, то Java выполняет «конкатенацию строк», где преобразует целое число в строку и прикрепляет ее к концу другой строки. Ибо, в Java предусмотрена специальная поддержка оператора конкатенации строк (+) и преобразования других объектов в строки. Преобразования строк осуществляются с помощью метода toString(), определенного Object и наследуется всеми классами в Java.

Посему, прежде чем постить «типа» сравнение - думай. Твой пример, мягко говоря, крайне некорректный для сравнения.

tz4678 ★★ (20.11.21 21:17:39)

… А C++/Java - это языки со слабой типизаций…

То что в языках С++/Java, в некоторых кейсах происходят эффекты «каламбура типизации и автоприведения типов» засчет подкапотной работы reinterpret_cast (С++) или особенностей системы преобразования типов в самой Java… То, это еще не делает их pure «слабо-типизированными».

Ехал auto, через auto…

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

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

Ага, ну. Я надеюсь это был сарказм или действительно такой недалекий? Особенно пример с полиморфизмом позабавил. С таким подходом и в JS тоже есть ООП, не ну а че, объекты же есть, значит и ООП есть!

интерпретируемым языком

В 2к21 деление языков на интерпретируемые и компилируемые не имеет смысла. Чем cpython отличается от runghc?

А, да. Cpython скомпилирует в байткод, поэтому питон — компилируемый язык.

А потом перебирает фреймы в бесконечном цикле. Точно не интерпретируемый.

Не упарывай чушь. Особенно, если не способен делать это убедительно.

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

И это не меняет суть аргумента. Когда хаскель интерпретируют (да, обычно только для разработки/дебага) — можно спокойно говорить о статически типизированных интерпретируемых языках и о вытекающи из этого выводом что термин «интерпретируемый» уже давно не нужен. Есть языки с хорошим статическим анализом и есть остальные, конкретно питон — в остальных. Тулзы, которые пытаются вывести типы, для питона есть, но они, ожидаемо, убоги.

Народ вон как в Java хочет писать

SomeBullshitAbstraction.VeryImportantBullshitObject.NextLevelBullshit.Bullshit=7

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

В джаве нет асинк/эвейт.

Рыночек растёт быстрее.

Есть.

Копай дальше. Ты ещё не добрался до самой мякотки - есть ещё и иврит и двусторонние тексты и вообще за рендер буковок на экране отвечает не юникод, а FreeType и HarfBuzz (потому что самого FreeType не хватило чтобы всякую сложную фигню рендерить). И строго говоря для того чтобы с рендером ака буковками работать, надо бы на их уровне работать, но вот они не для этого сделаны, потому ожидаю что скоро машинное обучение внесут для определения границ буковок которое со скринами экрана будет работать. Больше костылей богу костылей, как раз в духе современного IT.

Интерпретируемым может быть рантайм, не язык

Рантайм интерпретирующий.

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

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

Будто x86/x64-бинарник принципиально отличается от байткода в 2к21 когда его пытаются исполнять на m1 либо что-там-в-surface-вместо-процессора.

Ещё как отличается, там не эмулируется другая архитектура процессора.

Ну и высосано из пальца.

«Веб» слишком растяжимое понятие. Что конкретно тебя не устраивает? Ты считаешь, что из-за питона сайтики медленного открываются, или дело в экоповестке и низком КПД?

Мне больше NodeJS нравится просто на беке или PHP, ну а если прямо быстро-быстро надо, то возможно golang )

На самом деле это просто мои вкусы.

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

Если верить опросу на SO, то не настолько быстро.

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

Так тут важно что верх IT рынка едет в США/Германию/Канаду и по сути та же Украина просто донор квалифицированной IT рабочей силы.

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

Всё в IO утыкается в основном, тормозной CPython как раз в «вебе» узким местом является редко. Питон как всегда более взрослым чем нода и пых выглядел, так и продолжает, наращивая отрыв. В том числе из-за большего разнообразия и качества батареек.

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

И под конец шестой страницы они заметили :D

+1

ТС не утверждал, что есть. У вас двоих проблемы с чтением.

Очередной диагноз от вичера. Кудаж без него.

Доктор не дремлет!

Любая виртуальная машина, включая питоновую — потенциально архитектура процессора: https://en.wikipedia.org/wiki/Java_processor

Для питона такого нет тупо потому, что неинтересно, cpython’овая виртуальная машина редко кому нужна.

Любая виртуальная машина, включая питоновую — потенциально архитектура процессора

Только вымышленного, идеального и «переносимого».

вымышленного

java-процессоры существуют в дикой природе, x86-процессоры давно RISC внутри, кто из них вымышленный?

Джава-процессор не является виртуальной машиной.

Да он бред пишет. Насколько мне известно, Python, JavaScript и даже Java строки внутри хранят как 4-байтные кодепоинты (с таблицей юникода вроде совпадает). Так что для определения длины строки достатчоно ее длину в байтах поделить на 4. В UTF-8 и другие кодировки строки конвертируются только при выводе [в файл]. Базы данных такие как MySQL так же строки хранят в 4-х байтной кодировке (или 3-х, точно не помню). Об этом можно было и догадаться: смена кодировки баз или таблиц проходит мгновенно без перезаписи всех файлов с данными. Таким образом, использование однобайтных кодировок уменьшит лишь вес страниц, которые отдаются пользователю, но никак не скажется на размере тех же баз данных… Он еще упомянул что для определения длины строки нужно ее всю прочитать. Это верно только для PHP (функции с преффиксом mb_, например, mb_strlen) создатели которого решили не заморачиваться со всеми этими кодировками и строки у них - это просто байты (сишный char), тот же strlen там покажет sizeof(char[])/sizeof(char)

1. Может потому что даже с асинхронщиной ты получаешь один поток и лучше форкнуть воркеров что бы иметь несколько, а когда форкнул - то уже и смысл в асинхронщине есть не всегда. GIL же.

2. То же что и 1.

3. А надо? Если оно работает и работает хорошо - то почему бы не оставить как есть. Type annotations в питоне не играют никакой роли для интерпретатора, они только для программиста и его IDE. Не пишут наверно потому что дополнительно за это не платят, плюс это не всегда просто. Что ты называешь ABC контрактами, мне так и не удалось нагуглить. GoF-паттерны не используются, потому что с утиной типизацией они зачастую имеют очень мало смысла. Интерфейсов то тоже нет, кстати. И хотя их можно попытаться имитировать, получится ещё хуже чем без них.

4. Единственное что мертво в ООП - так это наследование. Однако в пайтоне оно есть и используется. Более того используются миксины, которые зачастую поощряют множественное наследование, и в таком случае не всегда ясно что ты в итоге получил за класс и как он должен работать.

Все-таки, Python не является Haskell, OCaml или каким-нибудь диалектом LISP. Это язык с элементами функциональщины, а не pure functional language, как Haskell. Так от чего не снабдить свой код asyncio, все граммотно оформить по ОО-дизайну с SOLID-принципами, четко разработь с event loop и прочим… Все какая-то портянка из 100500 глобальных def’ов вижу, в основном, в проектах. Да и вроде… Компании - солидные и платят этим Питонисам 250+ рублей в месяц. А стиль написания такой, за который могли бы уволить джуна в 2010ом, если речь шла про другой стэк (C#, Java).

Всё таки Python и не Java/C#, так почему бы не обойти стороной техники, которые ты предлагаешь? Что реально компания выиграет от их внедрения, кроме того что человек с джава майндсетом, вроде тебя, сможет читать код?

Вопрос: от чего же в новых питоновских проектах на живой практике многие разработчики не пытаются применить фичи из последней версии языка, и приблизиться к дизайну/стилю кода, как на Java. И вообще, все сделать по канону чистенько, соблюдая SOLID. При наличии уже таких возможностей.

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

Скорее первое. Но знаешь ли, зачастую этот «спагетти-код» проще читать и поддерживать, в отличии от бюрократии по твоему Java-канону.

И ещё я подозреваю что ты не видишь иерархии. В отличии от Java она образована модулями, а не классами, и код зачастую неплохо структурирован.

anonymous-angler ★ (21.11.21 16:40:46)

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

В одной из первых же ссылок на запрос в Гугле:

abc python contracts

https://stackoverflow.com/questions/3570796/why-use-abstract-base-classes-in-python

Short version

ABCs offer a higher level of semantic contract between clients and the implemented classes.

Long version

There is a contract between a class and its callers. The class promises to do certain things and have certain properties. There are different levels to the contract. At a very low level, the contract might include the name of a method or its number of parameters. In a staticly-typed language, that contract would actually be enforced by the compiler. In Python, you can use EAFP or type introspection to confirm that the unknown object meets this expected contract.

Так что, привел что я имею ввиду под «abc» в своем сообщении.

anonymous-angler ★ (21.11.21 16:40:46)

GIL же

Для Python v3.8+ (привет PEP554) с asyncio уже не такая проблема этот GIL, вроде.

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

привет PEP554

Ещё бы ты понял, что это и зачем.

WitcherGeralt ★★ (21.11.21 17:59:13) Ещё бы ты понял, что это и зачем.

Прекрасно понял, тебя комплексы съедают изнутри? Я читаю трэд, ты крайне неадекватно общаешься… Столько женских колкостей, мама воспитывала?

Еще бы здорово было, если бы ты общался, как взрослый и адекватный человек, а не школоло с кучей комплексов и пассивой агрессией. В реале такой же смелый или молчим сидим смирно в оффлайне? :) А весь пафос на ЛОРе, сугубо?

В одной из первых же ссылок на запрос в Гугле:

Окей, теперь понятно. Так то я погуглил «ABC contracts», но нагуглилось… Не то.

Так что, привел что я имею ввиду под «abc» в своем сообщении.

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

Для Python v3.8+ (привет PEP554) с asyncio уже не такая проблема этот GIL, вроде.

A Disclaimer about the GIL

To avoid any confusion up front: This PEP is unrelated to any efforts to stop sharing the GIL between subinterpreters. At most this proposal will allow users to take advantage of any results of work on the GIL. The position here is that exposing subinterpreters to Python code is worth doing, even if they still share the GIL.

Классная (нет) попытка объяснить своими фантазиями свои же фантазии. Прикол в том, что форумчане в курсе кто я в оффлайне.

ты крайне неадекватно общаешься…

Киса, не будь такой нежной. Если ты ты утрёшь слёзки и почитаешь внимательно, то обнаружишь за формой, причём достаточно корректной, содержание. Если же содержание не интересует, то не вылазь из своего safe space лишний раз, сэкономишь на платочках.

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

Аналогичная проблема с типами, развесистая система типов не поддерживается (трейты? Кейс классы недавно завезли и на том спасибо, хотя неудобные) и не нужна

Ну и библиотеки конечно. Какой толк писать асинхронный код, если внутри все равно все будет синхронно лол

Для Python v3.8+ (привет PEP554) с asyncio уже не такая проблема этот GIL, вроде.

asyncio не решает проблему GIL. asyncio применим только для очень узкого класса задач, которые в основном ждут I/O. Для всего остального он не нужен и ничего не даёт, а то и вреден.

Я забыл упомянуть ещё одно убийственное преимущество юникода: возможность в одном документе использовать сколько угодно языков. 8-битные кодировки такую возможность поддержать не могут в принципе.

Поэтому приход юникода был неизбежен и любые его костыли и неэффективности перевешивает один только этот аргумент.

WitcherGeralt ★★ (21.11.21 18:36:08)

и почитаешь внимательно, то обнаружишь за формой

Почитал про GIL еще раз внимательнее, в контексте Python v3 & PEP554. Да, признаю - я был неправ. Но, это только относительно теор. базы.

А насчет общения - останусь при своем, что все-таки общение не очень адекватное. Хотя признаю сам, что и сам не очень общался вчера. Так что, если что сорри чисто по-человечески.

WitcherGeralt ★★ (21.11.21 18:36:08)

Прикол в том, что форумчане в курсе кто я в оффлайне.

Ну и кто? :) Наркобарон или Джон Уик? :) Интересно, даже, стало.

WitcherGeralt ★★ (21.11.21 18:36:08)

Киса, не будь такой нежной.

Дорогуша, «кисой» меня плиз не называй. Если человек просит общаться культурнее, это не делает его мягким или женоподобным. Просто, знаешь есть тенденция, что люди в 30+ должны общаться адекватнее и спокойнее. Хотя, сам признаю честно, что сам порой не умею спокойно общаться.

P.S. вчера под винцом писал, когда без алко на форуме - адекватнее общаюсь.

Но пришел он в худшем виде из всех возможных

Ну и кто? :) Наркобарон или Джон Уик? :) Интересно, даже, стало.

Качок он. Илюха-присед, которому в бошку прилетело блином от штанги.

не является виртуальной машиной

С точки зрения языка и процесса разработки нет никакой разницы, железный процессор, или софтверный. А так-то можно бесконечно закапываться, типа «транзисторы это просто интерпретаторы электромагнитого поля» и т.д. до кварков. «Там дальше вниз одни черепахи» (с).

Слабенько, нужно было пошутить про любителя пожамкать питона.