К вопросу о кроссплатформности

[vitus_wagner]

Погонял сегодня ctypescrypto на разных платформах (после того как мне отрепортили баг, что на MacOS у меня динамическая библиотека неправильно ищется)

Под Windows пришлось поправить 1 тест. Любимая моя привычка - создавать временный файл и не закрывать. А потом удивляться - а что это на некторых платформах его по второму разу открыть не могут.

Под linx/armhf - ну даже не интересно.

Под pypy - работает. Сходу.

Под python3 - ожидаемо не работает. Для модуля который активно работает как с байтами, так и с юникодом, это неудивительно. Вопрос в том, а можно ли принципиально сделать этот модуль таким, чтобы был совместим с обоими версиями. По-моему нет.
Потому что полно объектов, у которых определены методы __str__ и __unicode__, которые должны быть переименованы, соответственно, в __bytes__ и __str__

Comments

[tanner-of-kha.livejournal.com]

Ну что значит "нет"? Есть же sys.version_info.

[vitus_wagner]

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

[gegmopo4.livejournal.com]

Ну можно и так, тоже вариант. Но у тебя там дифф будет очень маленький, и никакого вреда от __unicode__ или __cmp__ в Python 3 не будет.

[vitus_wagner]

C __cmp__-то это отдельная засада. Оно там в нижелещащем API именно cmp местами. Придется разбираться где там cmp только на eq/ne, а где действительно содержательный порядок сортировки. И тестов на это самое сравнение впятеро больше сначала написать надо.

[tanner-of-kha.livejournal.com]

Не думаю. Вообще напрашивается простенький миксин, который будет разбираться с версией и жонглировать методами через super(). Хотя тут ниже товарищи подсказывают six, это наверняка в нём реализовано.

[do-dodo.livejournal.com]

>Потому что полно объектов, у которых определены методы __str__ и __unicode__, которые должны быть переименованы, соответственно, в __bytes__ и __str__


а как же модуль six и декоратор @six.python_2_unicode_compatible?

[vitus_wagner]

Не, не поможет. В большинстве случаев мне от str не это нужно.

[amarao-san.livejournal.com]

six не помогает? Вроде, специальная либа для "кросс-питоновской" разработки.

[vitus_wagner]

Не-а, не помогает. В принципе b'' литералы в python 2.7 и u'' в python 3.3 и так есть.

Оно в основном решает проблемы совместимости переименованных стандартных модулей. НУ еще всяких встроенных функций вроде print и exec.

А определять методы __bytes__ и __unicode__ оно не помогает.

[onanim.wordpress.com (from livejournal.com)]

"Потому что полно объектов, у которых определены методы __str__ и __unicode__, которые должны быть переименованы, соответственно, в __bytes__ и __str__"

Объекты рефакторить, унаследовав от того, что будет данные методы определять в зависимости от версии.
См. также https://docs.python.org/3.3/howto/pyporting.html#str-unicode

В крайнем случае, в Makefile или чего там засунуть 2to3 .

[vitus_wagner]

А смысл? Дешевле две разные ветки поддерживать. Тесты все равно и там, и там гонять.

[gegmopo4.livejournal.com]

Поддержку двух версий в Питоне сделать не сложнее, чем поддержку, допустим Linux и Solaris в C с помощью препроцессора. if может быть и в теле класса. А часто можно вообще не париться и предоставлять оба интерфейса, Python 2 и Python 3, если не конфликтуют (например __cmp__ и __lt__).

Глянул, вот несколько советов/замечаний.

Не нужно определять пустой __del__, сборщик мусора этого не любит. Лучше вообще не надеяться на __del__ и предоставить явные методы для очистки. А заодно и поддержку протокола контекстного менеджера (__enter__/__exit__), если это имеет смысл.

В __eq__ нужно сперва проверять тип правого операнда. Если что-то левое — возвращать NotImplemented. Аналогично __ne__ должен проверять возвращаемое значение на NotImplemented. Впрочем, в последних (или грядущих) багфиксовых выпусках умолчальный __ne__ делает всё, что нужно, определять его явно будет не нужно.

Пока API не устоялось, многие безаргументные методы можно было бы сделать свойствами. self.oid.longname выглядит лучше, чем self.oid().longname(). Вижу, местами ты используешь свойства, но непоследовательно.

В нескольких местах пропущена пустая строка между методами.

[vitus_wagner]

Спасибо за замечания.