Python 3.13

Вот у меня С++ код импортится в python через SWIG. В C++ коде есть строки аки текст (std::string) и некоторые сырые данные которые передаются через тот же std::string и собираются/разбираются через struct.pack/unpack. В py2 это все прекрасно работало.

Теперь берем py3 и начинается какая то свистопляска с кодировки и прочим. Что бы эту свистопляску победить (и гонять сырые данные) приходится ВСЕ строки из SWIG автоматом конвертить в bytes, есть у SWIG такая опция. Ок. Но дальше, что бы передать/получить в/из C++ ОБЫЧНУЮ строку типа ‘myfile.dat’ мне приходится везде к этим строкам пихать encode/decode или префикс b.

Бесит это неимоверно, особенно с учетом того что такие ошибки вылезают только в рантайм и далеко не сразу. Аффторы этой гениальной идеи с разделением на bytes/str явно че то не додумали, сделано абсолютно по уродски.

Я уж не говорю про то что 3/2 раньше давало 1 а теперь 1.5, вот за такое точно надо бить канделяброй. С одной стороны они пытаются сделать из питона сурьезный ЯП, с другой привносят в него фичи недоязычков для домохозяек.

Я уж не говорю про то что 3/2 раньше давало 1 а теперь 1.5, вот за такое точно надо бить канделяброй. С одной стороны они пытаются сделать из питона сурьезный ЯП, с другой привносят в него фичи недоязычков для домохозяек.

для меня python2 и python3 разные языки

это как vb.net, который с какой-то радости назвали visual basic, который к vb6 вообще не имеет отношения. проще было бы оставить только c#, а «c# который хочет походить на vb» просто бы не делали, оставив оригинал. так же и с py2. например, perl5 и perl6 даже не скрывают что это разные языки, второй даже переименовали и живут оба.

3/2 раньше давало 1 а теперь 1.5

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

3/2 раньше давало 1 а теперь 1.5, вот за такое точно надо бить канделяброй.

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

Конечно, старые программы от этого перестанут выдавать привычный результат.

Конечно, старые программы от этого перестанут выдавать привычный результат.

И выдавали ли они вообще «правильный» результат

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

Вы неправильно думали, людей пишуших на C/C++/gnuplot etc такое удивляет безмерно.

в статически-типизированных язык все иначе

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

3 // 2 работает как тебе надо

с т.з. обратной совместимости надо было 3/2 оставить как было, а вот 3//2 сделать по новому. Мелочь же, но сколько с ней головняка даже при переводе 2to3… особенно с учетом утиной типизации.

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

Нет ничего неудобнее и страшнее чем слом обратной совместимости. Скажем есть формат SEG-Y для результатов сейсморазведки, он появился еще в те незапамятные времена когда данные хранились на магнитных лентах а чиселки были в IMB floating point. Прошло больше полувека - и до сих пор в нем используется IBM Floating point. Речь идет о передаче терабайтов данных между организациями, но все равно - IBM floating point. Все средства обработки принимают и выдают IBM floating point, преобразуя внутри себя эти терабайты в IEEE и обратно. И это правильно, можно взять старый файл полученный 50 лет назад и он будет корректно читаться.

старые программы от этого перестанут выдавать привычный результат.

Старые программы от этого перестанут выдавать ПРАВИЛЬНЫЙ результат.

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

Ну да, ну да… В C++ не будет 1… Он, конечно, выведет 1.5, если написать (double)3/2, так как автоматически приводит типы справа… В «новом» питоне как раз таки привычное поведение для любого скриптового языка, в старом совершенно идиотское с точки зрения любого человека, который не имел опыта с тупизацией

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

Ну да, ну да… В C++ не будет 1… Он, конечно, выведет 1.5, если написать (double)3/2, так как автоматически приводит типы справа…

Мдя… Вы элементарных вещей не знаете. Вне зависимости от статической/динамической типизации тип результата определяется ТОЛЬКО ТЕМ КАК РЕАЛИЗОВАНА ОПЕРАЦИЯ И БОЛЬШЕ НИЧЕМ. ничего не мешает для пользовательских типов перегрузить в плюсах

С operator / (A, B);

и в питоне

class A:
   def __truediv__(self, other): return C(...)

Понятно почему Вас так рекрутеры пугают.

Вот у меня С++ код импортится в python через SWIG.

Рекомендую обратить внимание на pybind11. Весьма достойный проект.

сырые данные которые передаются через тот же std::string

Ну и зачем же так делать? :) Вы же понимаете, что авторы таких проектов как SWIG, pybind11 итд будут предполагать, что string это, внезапно, строка, содержащая символы. Почему бы сырые данные не передавать в vector<uint8_t>?

Изначально SWIG выбирался за минимальное число телодвижений при биндинге. Все остальное, ЕМНИП, требует ручной обработки каждого элемента класса который хочется забиндить.

Почему бы сырые данные не передавать в vector<uint8_t>?

Потому что это требует инстацирования еще одного шаблона, а строка уже есть готовая?;-) Но я подумаю, спасибо.

старые программы от этого перестанут выдавать привычный результат.

Старые программы от этого перестанут выдавать ПРАВИЛЬНЫЙ результат.

Где гарантия что старые шизофренические правила обеспечивали верный результат вне искусственных тестов? :)

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

Понятно почему Вас так рекрутеры пугают.

Они это не спрашивают. Максимум могут зачитать вопросы по листку и записать ответы - все. Больше 30 секунд общения с женщиной можно выдержать только если она твоя мать или мать твоих детей

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

int/int –> int потому и только потому что так реализована операция деления int на int, статическая/динамическая типизация тут вообще не при делах. Нет никакого правила что тип результата любой операции (или операции деления) такой же как у левого операнда. Беда не в том что Вы глупость ляпнули (у всех бывает) - беда в том что Вы на этой глупости встали и стоите насмерть.

Больше 30 секунд общения с бабой можно выдержать только если она твоя мать или мать твоих детей

Боюсь что при таком подходе дети у Вас будут только если Вы выступите донором спермы… ;-(

Аффторы этой гениальной идеи с разделением на bytes/str явно че то не додумали, сделано абсолютно по уродски.

в 2 были параллельные пляски с str/unicode, их же переименовали просто. Не решая проблемы.

std::string

py3 и начинается какая то свистопляска с кодировки и прочим.

конвертить в bytes

приходится везде к этим строкам пихать encode/decode

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

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

Аффторы этой гениальной идеи с разделением на bytes/str явно че то не додумали

у той же java у строк тоже есть внутреннее представление и оно не не utf8. просто скопировать какой-нибудь буфер и вернуть как строку не получится не только в питон, но и в любой ЯП где строки это строки, а не байты

у каждого языка свое представление строк.

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

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

За это отвечает биндинг.

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

Не, конечно можно изгалится и хранить строку в виде списка 4х байтовых символов например. Но хочу напомнить - изначально питон под капотом содержал сишные типы, в Python.h и пр. хедерах это четко видно. Хотите прикрутить поверх еще че то - да пожалуйста, только старое оставьте как есть.

тебя куда-то не туда понесло

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

второй раз повторяю: внутреннее представление строки в питоне зависит от версии самого питона и от символов самой строки.

За это отвечает биндинг.

это не так, раз ты пишешь, что в питон у тебя возвращаются bytes и ты потом зовешь decode(). если бы «биндинг отвечал» были бы строки, а не байты

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

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

это даже мне - человеку который на С программировал самую малость, а про С++ только слышал - и то понятно

Хотите прикрутить поверх еще че то - да пожалуйста, только старое оставьте как есть.

Тебе и оставили твой питон курильщика, а для нормальных людей сделали третий - питон скриптобогов… Твои проблемы просто никто не понимает… Даже уродливая джанга и та перешла на питон 3 в 2013 году еще, и то что она тормозила с переходом позволило приобрести популярность всяким bottle, cherrypy, tornado… Ты как из криокамеры вылез

Кстати, Джанга и с переходом на асинхронщину до последнего брыкалась… Тоже на 5 лет переход затянули… Хотя вебсокеты как стандарт давно прижились

асинхронщину

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

то что она тормозила с переходом позволило приобрести популярность всяким bottle, cherrypy, tornado… Ты как из криокамеры вылез

CherryPy старше Django. А Tornado и bottle — продукты из других категорий.

Это сахарок над генераторами и неблокирующими сокетами, которые слушаются в цикле (asyncio.run() запускает этот цикл). Никакой ошибки нет, есть более рациональное использование имеющихся ресурсов при наличии факта неопределенности в виде GIL, который был введен чтобы потоки не могли попытаться одновременно изменить значение глобальной переменной… Для борьбы с GIL ввели и multiprocessing… Выпиливание GIL не делает асинхронщину бесполезной и не дает тредам преимуществ над однопотоком хоть и ускоряет их

И что? Они раньше перешли на прекрасный Python 3 с его замечательными строками!

GIL, который был введен чтобы потоки не могли попытаться одновременно изменить значение глобальной переменной… Для борьбы с GIL ввели и multiprocessing…

это заблуждение. GIL существует не для этого.

GIL не решает проблем конкурентного доступа в многопоточных программах на питоне, не делает доступ «synchronized».

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

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

async/await и GIL явления никак не связанные, у тебя какая-то каша.

async/await не решает проблему GIL.

повсеместное внедрение async/await - это ошибка, она возможно будет признана позднее.

Решают. Нам потоки не нужны, а значит и GIL не будет мешать. Правда придется через всякие uwsgi запускть множество инстансов… Но это для апишек всяких

Решают. Нам потоки не нужны, а значит и GIL не будет мешать

разверни пожалуйста мысль.

Нам потоки не нужны

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

У нас есть один поток. В нем есть основной цикл, который работает с неблокирующими сокетами, и дергает тот или иной обработчик по мере того как сокет готов для чтения/записи… Или что непонятно? Оно быстро работает, если не производится каких операций, жрущих проц. Это просто перекладывание байтиков из сокета в сокет…

При работе нескольких потоков GIL обеспечивает атомарность операций. В момент любой времени N выполняется лишь один опкод. Что грустно в плане производительности…

А вот есть всякие Go, где нет тредов, асинхронности, тебя избавили от необходимости управлять этим — лишь запускай горутины через go doStuff(), но там нет GIL, поэтому нужно пользоваться мьютексом, а в питоне у тебя есть куча thread-safe операций (она для этого должна занимать один опкод)…

Если твое приложение работает с сокетами, ты там, например сканируешь сеть, делаешь запросы или наоборот их обрабатываешь, то асинхронный вариант как правило быстрее тредов (не надо смотреть примеры, где дебилы числа фибоначи вычисляют с помощью asyncio, сравнивая с multiprocessing и тп — тут только сетевые код сравнивать надо)

У нас есть один поток. В нем есть основной цикл, который работает с неблокирующими сокетами, и дергает тот или иной обработчик по мере того как сокет готов для чтения/записи… Или что непонятно?

ты некомпетентен и пытаешься умничать.

разберись для себя что такое многопоточность и зачем она нужна, потом разберись как работает GIL, тогда тебе станет понятно, что async/await проблему GIL не решает.

При работе нескольких потоков GIL обеспечивает атомарность операций

сообщением выше ты же пишешь:

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

запутался что ли?

питоне у тебя есть куча thread-safe операций

погуглил? молодец. но есть нюансы:

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

2. дефиниция этих гарантий расплывчата: operations … that “look atomic” really are. программы не пишут на основе таких спецификаций, для практического использования это не годится

но там нет GIL, поэтому нужно пользоваться мьютексом, а в питоне у тебя есть куча thread-safe операций

3. гарантировано атомарные операции есть много в каких языках при этом без всякого GIL, и есть даже операции гарантирующие hb, видимость. поэтому этот твой аргумент он странный весьма.

но там нет GIL, поэтому нужно пользоваться мьютексом

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

ты некомпетентен и пытаешься умничать.

Пишет эксперт, думающий что асинхронность вся эта не нужна, ее какие-то дурачки придумали и GIL тут непричем. Ясно

гарантировано атомарные операции есть много в каких языках при этом без всякого GIL

Ага запусти 100500 тредов и инкрементируй глобальную переменную в том же C++, потом результат скажешь

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

Набор слов.

пытаешься умничать

И обвиняешь в этом других

эксперт, думающий что асинхронность вся эта не нужна, ее какие-то дурачки придумали и GIL

еще раз: async/await проблему GIL не решает, и async/await был добавлен в питон по другим причинам совершенно.

гарантировано атомарные операции есть много в каких языках при этом без всякого GIL

Ага запусти 100500 тредов и инкрементируй глобальную переменную в том же C++, потом результат скажешь

глупенький, атомарные операции есть и в Java и в С++ и везде. думать что атомарные операции есть только в питоне и благодаря GIL - это большая глупость. атомарные операции в тех же java и С++ часть атомарны бесплатно, но не устанавливают HB и не обеспечивают видимость, часть достигаются доп. ключевыми словами и доступны для более широких типов. то что ты не знаешь, что значит атомарная операция и что они есть в других ЯП, говорит только о твоей некомпетентности.

а вот «атомарный инкремент» ты приплел совершенно зря, «операция» инкремент традиционно не атомарна.

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

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

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

Набор слов.

для тебя конечно это бессмысленный набор слов, с твоим-то нулевым уровнем и самомнением

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

ASCIIZ, Pascal, Haskell, std::string, QString, std::stringstream, std::crope …

хм:

есть сети Петри как модель конкурентного(и или параллельного) редукции

чем асинхронщина|распределённость|папалельность|.... выбивается из ряда способов максимизировать выхлоп уменьшая издержки на код?

он не знает про неблокирующие сокеты. программирование сокетов это ж великая наука доступная только… да хз я думал их все пробовали хоть раз, но нет тут оказались еще илитарии, которые ушли в отрицалово и 10 лет игнорировали весь прогресс в мире программирования на питоне

https://learning-python.com/python-changes-2014-plus.html

деды знают

я-то в отличие от тебя это всё прекрасно знаю, и зачем нужен асинк/авейт прекрасно знаю.

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

Покажи мне свой код с асинками тогда поверю… Или на худой конец парашу эту с тредами и очередями, где ты там даже тридпулэкзекутор не используешь…

TypeError: can only concatenate list (not «dict_items») to list

прикольно. str(b'abc') выдаёт тип строка, хоть и является какой-то мурзилкой внутри

зато dict.items() у нас теперь не list, а некий dict_items, и его надо называть Капитан list(dict.items())

вы уж определитесь, вы за белых или за красных?

а, ну тут логика есть, видимо это итератор а не список как раньше. ладно, это мелочь жизни.

10 лет игнорировали весь прогресс в мире программирования на питоне

Так прогресс в мире программирования или на питоне?

зато dict.items() у нас теперь не list, а некий dict_items, и его надо называть Капитан list(dict.items())

Претензии уровня пихать в жопу банки было раньше удобнее. Их не надо пихать куда не следует… Я не пользуюсь вторым питоном более 10 лет и радуюсь жизни, и я уже забыл насколько он был «прекрасен».

вы уж определитесь, вы за белых или за красных?

За голубых (просто люблю голубой цвет). Так пойдет?

Покажи свой код

Под капотом там вроде бы одно из трех:

1. нуль-терминированная С-строка
2. строка (массив байт) с длиной в отдельном поле
3. нуль терминированная строка с длиной в отдельном поле

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

Прогресс - это просто развитие языка в третьей ветке. Вторая не развивалась с 2010, там лишь правились ошибки

Лично мне по большому счёту этот прогресс и не нужен был никогда. С одной стороны, мечталось бы о языке, который просто стабилен, просто идеален и лишь правятся ошибки. С другой - поддерживать инфраструктуру, биндинги. С третьей - сколько там версий lua одновременно сейчас поддерживается? Вообще не в теме. Или tcl. Думаю, если бы python2 не похоронили а вывели бы в отдельную ветку, сообщество у него было бы больше чем у конкретной версии lua или tcl, и как-нибудь худо бедно всё это поддерживало. Но добровольно-принудительный переход с py2 на py3 заставил сообщество смириться и переобвыкаться. Грустно, конечно, но хотелось бы как с perl 5 и perl 6, а не как с python2 и python3.

Хороший был язык для домохозяек.

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

В дистрибутивах по умолчанию 5.1, выпущенная в 6-ом и прекращена поддержка в 12-ом. Актуальная сейчас - 5.4.

Нет.

std::string = два указателя

std::rope = бинарное дерево массивов

Haskell = односвязный список

В рамках юникода ещё бывает массив байтов с динамическим чтением символов, массив символов, массив графем.

Думаю, если бы python2 не похоронили а вывели бы в отдельную ветку,

Он никому не нужен, потому что глобальных проблем не решает.

Но добровольно-принудительный переход с py2 на py3 заставил сообщество смириться и переобвыкаться.

В 2010 «заставили», перестав развивать язык, лишь изредка правя баги типа ошибок ssl

Грустно, конечно, но хотелось бы как с perl 5 и perl 6

Raku вообще другой язык. Его столько ждали, что успели перейти на PHP или Python, и когда он вышел, то оказалось что никому уже не нужен… А Perl 5 поддерживают, потому что некому переписать всякие скрипты для automake и git на Python

ничё не понял. почему мы в файл пишем байты, а когда я делаю file.read() у меня получается почему то тип str?

некому переписать всякие скрипты для automake и git на Python

И переписывать их снова и снова, да.

stripes(которые ropes) для быстрого редактирования

а вообще AТД строка и васякот

а, ну тут логика есть, видимо это итератор а не список как раньше. ладно, это мелочь жизни

То есть ты сейчас только что в первый раз в жизни попробовал сделать items() дикту в третьем питоне. Правильный ли я делаю вывод, что до сего дня ты третий питон ни разу не запускал?

Правильный ли я делаю вывод, что до сего дня ты третий питон ни разу не запускал?

Запускал. Но немножечко не так.

А как?

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

благодаря := ща почти любой код можно заоднострочить

так что как раз как только := вкорячили так всё

https://mathspp.com/blog/pydonts

А зачем его однострочить?

python -c "<ENTER>
dquote> ...<ENTER>
dquote> "<ENTER>
...

Я повторю вопрос. То есть пятнадцать лет до сего дня, ты третий питон не пробовал? И когда вонь развел в этом топике, на тот момент ты тоже питон3 не пробовал. Всё правильно?

https://mathspp.com/blog/single-line-calculator

не всякий cli :(

https://mathspp.com/blog/single-line-calculator

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

python2 благодаря своей неряшливости позволял делать элегантные однострочники

Как ты ёмко объяснил почему мне нравится Tcl.

Файл открывается или в бинарном или в текстовом режиме. Во втором случае ещё обычно можно указать кодировку, но хз как в Pytohn.

то есть, str без аргументов выдаёт b", а open без аргументов открывает, как строку? логично, чего же тут нелогичного то.

str без аргументов выдаёт b"

>>> str()
''
>>> str
<class 'str'>

Файл открывается или в бинарном или в текстовом режиме. Во втором случае ещё обычно можно указать кодировку, но хз как в Pytohn.

Если в текстовом, по умолчанию считается, что кодировка utf-8 (зависит от платформы). Если окажется иначе — падает с ошибкой чтения. Можно указать кодировку явно.

интернирования

это даже мне - человеку который на С программировал самую малость, а про С++ только слышал - и то понятно

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

UPD почитал дальше, ты на скале не писал случаем, работу не ищешь? У меня есть вакансия открытая, я бы рекомендовал

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

жаль :)