>> Раз школота их мешает в одну кучу, значит, это школота написала Питон.
> Нет, только то, что его разработчики пошли на поводу у школоты :) В данном случае они пошли на поводу у традиции, потому что она банально освящена временем. И только набрав опыта и набив шишки - начали осознавать, чем плохи такие решения. Или же не имели возможности провести нужные решения раньше, пока вся масса не сдвинется.
Вон с тем же делением Вирт возмутился раньше. Но где теперь та Модула? И где Си, в котором на проблему успешно плюнули?
>> Потому что она в принципе позволила при проектировании языка делать неявные
>> конверсии из (big)int во float.
> Да, отмена таких смешений типов - и есть более корректный (с точки
> зрения
> математики) путь. Но выбрали, увы, нечто более "по заявкам трудящихся".
Опять-таки вопрос в грандиозности реформы после того, как язык был реализован по принципу "возьмём то, что делают большинство на момент этого проектирования, а потом будем разбираться, что было неправильно". На сейчас отменять автоконверсию int->float значит, мне кажется, делать ещё более суровый перелом, чем при создании 3.0.
>>> Для обеспечения подобной совместимости - люди написали сторонние модули, напр. six.
>>> Нет никакой нужды было тащить это в потроха CPython.
>> Посмотрел, ужаснулся, спасибо. Если мы ещё и это будем дёргать на каждый
>> чих... тут и так каждая лишняя функция проверяется на то, нельзя
>> ли обойтись без неё, потому что вызов функции - страшно дорогое
>> действие. А ещё и, например, six.b() на каждый такой литерал?
> Сколько-ж именно их у вас? "Чую бесовщину" (ц)
Ой много. Все основные ключевые слова и распространённые значения параметров из SIP'овских RFC, из стандартных словарей RADIUS, словаря Cisco, собственного словаря...
Но six.b() на константы ещё полбеды, это можно организовать при загрузке модуля (думаю, сильно скорость не пострадает). А вот то, что в ряде случаев (этак несколько сотен) нужен именно dict.items() как список, а рисовать всегда list() это означает вызов ещё одной функции и потерю на этом... даже код на 2.* при подготовке этого перехода уже потеряет в скорости. А что будет, когда переход закончится - ХЗ.
Я уже подумываю взять какой-то стандартный препроцессор типа m4 и прогонять код через него. В рантайме это будет явно дешевле six'овских вызовов.
Кстати, именно тему получения списка ключей/атрибутов/пар six не закрыл. Я понимаю, что для него list() вокруг уже готового списка ерунда, но я тут за каждый call per second бьюсь.
>>>> Тут меня больше всего удивляет, например, игра между range и xrange, items
>>>> и iteritems... Зачем было убивать старое понимание?
>>> А зачем его сохранять, если py2 и py3 все-равно несовместимы? Или
>>> вы против самого изменения?
>> Да, я считаю, что оно не нужно. Ничего вредного в xrange, dict.items()
>> который выдаёт список и т.п. - не было.
> Лишние интерфейсы. Сейчас range возвращает итератор, а последовательности (list, tuple,
> etc) - можете получить, натравив на это соответствующий конструктор. И
> не нужно никаких дополнительных iteritems.
Только вот измерения показывают, что на 2.7 на большом словаре (я брал в качестве характерного размера 10000) list(d.iteritems()) дороже d.items() на четверть. Это уже даёт проблему на самом переходе: я для него должен, получается, заведомо замедлить программу. После этого, да, переход на тройку уже ускоряет. (Полный цикл - 4.0 на 2.7/items, 4.5 на 2.7/list(iteritems) и затем 3.3 на 3.3/list(items).) В общем, переход не гладкий.
> Другое дело, что обеспечить совместимость здесь было гораздо проще чем со строками
> (там вообще - непонятно как это сделать). Видимо, просто решили
> не заморачиваться, раз интерпретаторы несовместимы все равно...
Похоже на то. Но про строки я не согласен - там плавный переход тоже делается без особого напряга.
