а как в этом вашем пихтоне правильно обходить несовместимость версий?

Несовместимость 2 и 3 ветки принято обходить с помощью специальных библиотек. Правда, код получается как говно.

пока что сделал через try-except, но может есть более красивые решения для этого?

А чем это некрасивое решение? В общем-то, более логичным будет проверять sys.version и в зависимости от него делать то либо другое.

конвертить код штале? фу

использовать для второго from codecs import open, наверное

я нубас в программировании в целом и в питоне в частности. поэтому не знаю, что красиво, а что не красиво

sys.version, похоже, парсить надо. нет ли чего-нибудь, что выдаст только версию питона?

и ещё, почему третий питон не может открыть файл как утфный?

ээ пэрэвэди

о, работает, спасибо. а в чём соль-то и почему третьему это не нужно?

конвертить код штале?

Ты уж выбирай - тут либо на [censored] сесть, либо рыбку съесть.

потому что в третьем open работает, как во втором codecs.open, вестимо :)

На истину в последней инстанции не претендую, но я бы вынес все спорные моменты в отдельные функции с общим префиксом. И уже внутри этих функций все проверки версии и нужные/ненужные костыли: v2v3_open(...), v2v3_somefunc1(...)

ну, то есть, питон второй-то открывает его нормально. и сам файл врядли будет отличаться по двоичному содержанию, если его сохранить именно в утф-8. так почему же третий питон спотыкается при его открытии в формате утф8?

рыбку не ем - веган, никуда не сажусь - стрэйт эджер с уже имеющейся бабой. я вообще про адаптацию самого кода

отлично, ещё раз спасибо

суть проблемы непонятна. он и так по умолчанию открывает его в utf-8

Python 3.4.1 (default, Jul  6 2014, 20:01:46) 
[GCC 4.9.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> open('utf8.txt').read()
'Привет, мир. Я текст в utf-8.'

а может, в третьем open - это и есть codesc.open? а в питон второй это не пропихнули для сохранения совместимости?

тоже можно, но для моего скрипта в пару строк это слишком громоздко

проблема как раз в том, что мой файлик не открывается в utf8, в третьем питоне нужно насильно указать кодировку latin1. а во втором - нет

>>> if '2.7' in sys.version:
...     print "Okay"
... 
Okay
>>>

Что там парсить-то?

хитро. я учусь на собственном опыте. пока что такая штука мне не была нужна, поэтому я не в курсе про неё. алсо, не слишком надёжно на первый взгляд, вдруг выйдет какой-нибудь там gcc 4.9.2.7 или python 3.2.7

логично. потому что во втором по умолчанию оно как набор байт, а в третьем - как строка (unicode).

царь перешёл на питон?

Лучше использовать идиомы языка, на котором пишешь, иначе часто получаются довольно велосипедные конструкции.

gcc 4.9.2.7 или python 3.2.7

Я лишь показал куда копать, да и выше про version_info правильно написали. Защита от проблем в коде вроде тех, что ты написал, это вопрос полноценной реализации.

Что простите?

не слишком надёжно на первый взгляд, вдруг выйдет какой-нибудь там gcc 4.9.2.7 или python 3.2.7

if sys.version.startswith('2.7.5'):
    print "Okay"

А вообще есть еще более «точный» способ:

>>> sys.version_info
sys.version_info(major=2, minor=7, micro=5, releaselevel='final', serial=0)
>>> sys.version_info.major
2
>>> sys.version_info.minor
7

open(exim_log_file, 'rb')

А вообще, третьепитон, с его форсированными плясками вокруг юникода, не предназначен для обработки строк.

я один читаю снейк кейс, заикаясь? EximLogFile vs exim_log_file. я не ради флейма, мне на самом деле интересно - это дело привычки или нет?

Лучшее сферическое решение в вакууме: используй только третий.

мне кэмел кейс напротив кажется менее читабельным. алсо, вот: http://www.gnu.org/prep/standards/standards.html#Names

For example, you should use names like ignore_space_change_flag; don’t use names like iCantReadThis.

на серваках только второй пихтон, а мне хочется использовать его где-нибудь ещё и на будущее

вот это, кажется, ещё лучше. спасибо

VPS.

поясняю: на продакшен-серверах хостинг-провайдера, системным администратором которого я являюсь

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

Автору стоит посмотреть описание модуля двойки __future__ - иногда проще добавить импорт каких-то фич из двойки в тройку, чем писать костыли.

«Из тройки в двойку», конечно же.

Ифать придётся. Питонщики же хотят красивую стандартную библиотеку, без поддержки легаси как в похапе.
Так что страдай.

чего ж тут страдать, я сделал вот так: а как в этом вашем пихтоне правильно обходить несовместимость версий? (комментарий)