Python 3.13

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

Не, конечно можно изгалится и хранить строку в виде списка 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 - это ошибка, она возможно будет признана позднее.

Тогда уж давайте чтобы быть последовательными начнём с начала. Строка это вектор из байт + его длина на уровне битов и байтов, но также это информация о том, что это именно строка символов (на это намекает сам тип). И тут мы подходим к вопросу отображения. Если бы речь шла об отображении байтов, то строго говоря логичнее всего было бы отображать численные значения этих байтов (ведь не факт, что за последовательностью байтов прячутся именно символы ascii или другой кодировки). Т.к. кодировок более одной, весьма логично для преобразования чисел в символы и обратно имеются методы encode и decode в 3м питоне. В чём тут проблема решительно не понятно. Простите за банальность, но каждый символ это байт(или несколько), но не каждый байт это символ. И разделение на символы и байты, очевидно, должно быть.

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

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

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

Тебе только в этой теме несколько человек намекнули, что набор байтов и строка это в питоне разные вещи. У тебя синдром утёнка и ты не приемлишь decode? Хочешь свой родной str()? Так используй str(b, encoding="utf-8"). Серьёзно, ты пробовал документацию открывать?

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

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

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

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

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

Все так, но вопрос в умолчаниях при определении типа отображения. Те умолчания которые были в py2 были лично мне удобны, а те что есть сейчас в py3 лично мне крайне неудобно.

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

Тебе только в этой теме несколько человек намекнули, что набор байтов и строка это в питоне разные вещи.

нахрена это сто раз писать если это очевидно? вопрос не в этом. str возвращает строку. не набор байт, не класс ProektirovshikDebil, а именно строку.

В Java, JS, PHP, C# и тд есть волшебные методы toString/ToString, которые возвращают текстовое представление объекта, приведение объекта к строе в них приводит к вызову этого метода. В Питоне точно так же как в остальных языках. Прекращай уже…

Мне это вообще неинтересно. Я только про один факт - добавлять b" это неадекватность, разработчики неадекватны. Это всё, что я сказал. Я не знаю, зачем вы с этим спорите какими-то явами. Тут только доступ к медицинской карте может что-то показать.

str не должен добавлять b". во всех языках, как бы приведение байт к строкам не вызывалось, оно не корёжит данные. если бы функции str вообще бы не было, и были только другие способы, это можно было бы принять. но она есть, и от этого не отвертеться. и она делает не то, что должна. хотя в py2 отлично работала и выполняла свою функцию. всё. какие явы? где в яве функция «покорёжь мне строку»? оно или переводит в строку, или нет. «перевести в строку но при этом покорёжить» там есть?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В C23 вот K&R-style декларации убрали, сломали же ж, ужас.

Синтаксис объявления функций K&R объявили устаревшими в самом первом черновике стандарта в 1988-ом году. Компиляторы на этот синтаксис выдают предупреждение с самого появления стандарта, но продолжают собирать этот код под настоящее время.

Python не имеет спецификации, и определяется реализацией (насколько я понимаю).

а вот насколько я понимаю, питон определен документацией, а вовсе не сипитоном

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

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

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

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

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

Набор слов.

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

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

Строка это вектор из байт + его длина

нет. строка это не «вектор из байт + его длина»

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