2+3

[dzz]

До чего ж большое спасибо хочется сказать Гвидо нашему ван Россуму за отдельные нововведения в 3 питоне.

Имеем байтовый буфер вида x=b'12345678'

Привычное по второй версии struct.unpack('B',x[5]) вываливается со словами TypeError: 'str' does not support the buffer interface

А struct.unpack('B',x[5:6]) - работает.

Всё потому, что type(x[5]) - class 'int'. А type(x[5:6]) - class 'bytes'.

Поубывыв бы ;)

З.Ы. В общем, перепёр в первом приближении pyExcelerator на третий диалект. Докую - выложу на sourceforge в проект py3xcel.

Comments

[dzz.livejournal.com]

Пока сделал форк. Файлы уже грузит-разбирает, остальное нужно тестить.

Как грамотнее поддержать 2+3 и стоит ли это делать вообще - думаю.
Мне он, собственно, нужен под 3.1+

Интересно, как отдельные граждане кошерно поддерживают сразу 2 и 3 диалекты?
Надо, что ли, в cx_Oracle посмотреть, там оба варианта заявлены.

[avnik.livejournal.com]

chameleon, pyramid, самые базовые пакеты zope.* сейчас поддерживают обе ветки из коробки. Ну и используй пакет six -- там всякие условные определения -- компенсирующие разницу между 2 и 3.

[dzz.livejournal.com]

Надо выяснить, знают ли авторы six про найденную мной сегодня забавность в struct.unpack() ;)

[avnik.livejournal.com]

Когда я туда смотрел -- не знали. Но выбор между байтами/юникодом, местонахождение streingIO, СonfigParser и прочие странности нивелирует.

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

PS Но ты посмотри как в том же хамелеоне обходятся, там довольно глубоко лезут в потроха питона (аст и кодогенерация) и при этом поддерживают все основные ветки.