Python-сообщество

odnochlen
В общем, слайс всегда bytes, даже если он из одного элемента

в срезе может быть и ноль элементов

odnochlen
Такой вот привет из явы с byte и byte{}.

причём тут Java ?

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

Гм, то что речь шла о тройке - это я понял. Просто в двойке ваш пример работает и “зачем так сделали” я понял как вопрос относительно “изменений” 2.x => 3.x

py.user.next
в срезе может быть и ноль элементов

Может. И он все равно будет bytes.

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

odnochlen
что элементы в юникоде и байтах в тройке стали различаться

они привели их в порядок, сделав из двух типов строк один, так же, как из range() и xrange() сделали один незатратный range()

раньше то вон что было

Это тут вообще причем?

С range() и co правильно, незачем иметь 2 функции, одна из которых возващает список, а другая - (ит|ген)ератор, когда есть list().

odnochlen
Это тут вообще причем?

это всё - очистка второго питона от лишних конструкций
он очень экспериментальный

А где тут очистка, если в действительности происходит усложнение: в юникоде элемент имеет тот же тип, что он сам и срез, а в байтах - нет?

py.user.next
причём тут Java ?

В яве byte{} (парсер-лох) имеет то же поведение.

odnochlen
А где тут очистка, если в действительности происходит усложнение: в юникоде элемент имеет тот же тип, что он сам и срез, а в байтах - нет?

Гм, а где вы видели именно байты в двойке? Там было:
В тройке что-то вроде
А срез это вообще (по моему ) очень удачная замена для 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 (Июль 25, 2012 22:14:10)

EBFE
Гм, а где вы видели именно байты в двойке? Там было:

Они там были синонимом строки. Я просто выбирал названия так, чтобы не путать.

Ситуация в двойке меня вполне устраивает. Чтобы получить число из элемента, есть ord, обратно - chr.

EBFE
Или наоборот: пусть элемент в byte будет тоже списком:

Байтом? Или таки списком?

odnochlen
Байтом? Или таки списком?

В принципе, для примера без разницы.
Хотя бы вот так:

Отредактировано EBFE (Июль 26, 2012 02:12:58)