odnochlenв срезе может быть и ноль элементов
В общем, слайс всегда bytes, даже если он из одного элемента
odnochlenпричём тут Java ?
Такой вот привет из явы с byte и byte{}.
Полная версия: Питонобатхерт
odnochlenГм, то что речь шла о тройке - это я понял. Просто в двойке ваш пример работает и “зачем так сделали” я понял как вопрос относительно “изменений” 2.x => 3.x
В моем примере речь шла о тройке. Наверно, надо было это написать, хотя тройка тут считается практически дефолт питоном.
py.user.nextМожет. И он все равно будет bytes.
в срезе может быть и ноль элементов
EBFE, акцент был на том, что элементы в юникоде и байтах в тройке стали различаться: в юникоде элемент того же типа, а в байтах - нет, при том, что срез байтов, даже с одним элементом - байты. Получается усложнение.
odnochlenони привели их в порядок, сделав из двух типов строк один, так же, как из range() и xrange() сделали один незатратный range()
что элементы в юникоде и байтах в тройке стали различаться
раньше то вон что было
>>> range(10000000000) Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: range() result has too many items >>>
Это тут вообще причем?
С range() и co правильно, незачем иметь 2 функции, одна из которых возващает список, а другая - (ит|ген)ератор, когда есть list().
С range() и co правильно, незачем иметь 2 функции, одна из которых возващает список, а другая - (ит|ген)ератор, когда есть list().
odnochlenэто всё - очистка второго питона от лишних конструкций
Это тут вообще причем?
он очень экспериментальный
А где тут очистка, если в действительности происходит усложнение: в юникоде элемент имеет тот же тип, что он сам и срез, а в байтах - нет?
py.user.nextВ яве byte{} (парсер-лох) имеет то же поведение.
причём тут Java ?
odnochlenГм, а где вы видели именно байты в двойке? Там было:
А где тут очистка, если в действительности происходит усложнение: в юникоде элемент имеет тот же тип, что он сам и срез, а в байтах - нет?
object
| \
int \
basestring
| \
str(8bit) unicode(code points)
object
/ | \
| | \________
int | \
| \
str(code points) byte
) очень удачная замена для substr/copyOfRange/array_slice и.т.д (да еще и в синтаксе).Т.е не надо в зависимости от типа писать foo.substr/foo.copy(1,2,3). Вполне логично, что срез всегда возвращает тотже тип - если не путать срез ( x : y : z ) с доступом к одному определенному элементу foo(x)
.То что в str/unicode элементы тогоже типа - просто language design decision. Можно конечно спорить, но единственная альтернатива - ввести дополнительный тип (char) и продумать, что должен выдавать к примеру ‘x’ + ‘abc’, ‘x’ + ‘y’, foo.find('abc'), foo.find('a').
И кому от этого легче станет (благо пришлось бы и тут выбирать что-то одно - эрго были бы недовольные
) ?Или наоборот: пусть элемент в byte будет тоже списком:
Во первых: тогда вообще list(x) должен возвращать список - что бы все было унитарно (хотя так и до dict(x) дойти можно).
Во вторых: как добратся до конкретного байта? Вызывать что-то вроде byt_to_int(mybytes(x))?
И что тогда можно передать byte_to_int - только список с одним элементом? Если нет: то что использовать по умолчанию при преобразовании - BigEndian или LittleEndian?
И.т.д.
Тоесть: при работе c строками по моему не особо важно, состоит ли строка из отдельных символов или из строк с единичной длиной. И если можно не плодить сущности - почему бы и нет
При работе с списком обычно через индекс нужен доступ к определенному элементу (благо если действительно нужен “sublist/subarray” - можно использовать срезы).
EBFEОни там были синонимом строки. Я просто выбирал названия так, чтобы не путать.
Гм, а где вы видели именно байты в двойке? Там было:
Ситуация в двойке меня вполне устраивает. Чтобы получить число из элемента, есть ord, обратно - chr.
EBFEБайтом? Или таки списком?
Или наоборот: пусть элемент в byte будет тоже списком:
odnochlenВ принципе, для примера без разницы.
Байтом? Или таки списком?
Хотя бы вот так:
>>> type(b'x') <class bytes> >>> type(b'x'[0]) <class bytes>