LINUX.ORG.RU

шестой год попыток python3, вечная тема байтов и строк

 ,


0

3

в n-ный раз пытаюсь портировать хоть самые простые вещи на python3, и снова попадаю на байты и строки

в python2 было всё просто и понятно, есть str, есть unicode, и str всегда совместима с unicode

в python3 даже самый простейший код у меня нарывается на неприятности

в python2 был вот такой код:

def hsh(s):
    out = base64.urlsafe_b64encode(hashlib.sha256(s).digest())
    return out.replace('-', '').replace('_', '')[:8].ljust(8,'A')

всё работало отлично. в python3 же он говорит следующее:

  File "/today/51t/sx.py", line 12, in hsh
    out = base64.urlsafe_b64encode(hashlib.sha256(s).digest())
TypeError: Unicode-objects must be encoded before hashing

окей, байтуем, заменяем s на s.encode('utf-8'). получаем:

  File "/today/51t/sx.py", line 9, in hsh
    return out.replace('-', '').replace('_', '')[:8].ljust(8,'A')
TypeError: a bytes-like object is required, not 'str'

ну да, у нас теперь байтовая строка, а по слухам в третьем python они уже несовместимы. делаем out=str(out) или out=out.decode('utf-8'), без разницы... и получаем в итоге:

Traceback (most recent call last):
  File "run.py", line 3, in <module>
    import os, appw
  File "/today/51t/appw.py", line 60, in <module>
    appz[x]=parse_dir(x)
  File "/today/51t/appw.py", line 44, in parse_dir
    append_hashes(rootdir,n,subdir)
  File "/today/51t/appw.py", line 25, in append_hashes
    hashlist[dp+n] = hsh( open(dp + n).read() )
  File "/usr/local/lib/python3.6/codecs.py", line 321, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte

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

★★★★★

'utf-8' codec can't decode byte 0x89 in position 0

Может байт неправильный? Ведь в utf-8 допустимы однобайтные символы до 0x7F включительно, а дальше идут n-байтные. Если верить википедии, то первый байт может начинаться с битов 110, 1110, 11110 и т. д., а 0x89 в двоичном виде выглядит как 10001001.

aureliano15 ★★ ()
def hsh(s):
    out = base64.urlsafe_b64encode(
        hashlib.sha256(s.encode('utf-8')).digest()
    ).decode('utf-8')
    return out.replace('-', '').replace('_', '')[:8].ljust(8, 'A')
x77cc33x ()
Ответ на: комментарий от aureliano15

Может байт неправильный?

в хэше? откуда.

впрочем, покрутив, я уже отложил все попытки портировать, ещё лет на 6 :) я лучше на 2-м python напишу всё, что мне нужно :)

buratino ★★★★★ ()
Ответ на: комментарий от buratino

а какая строка на входе передается функции?

такто код рабочий

Python 3.5.2 (default, Nov 17 2016, 17:05:23) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> import hashlib
>>> 
>>> def hsh(s):
...     out = base64.urlsafe_b64encode(
...         hashlib.sha256(s.encode('utf-8')).digest()
...     ).decode('utf-8')
...     return out.replace('-', '').replace('_', '')[:8].ljust(8, 'A')
... 
>>> 
>>> hsh('FUCK FUCK FUCK')
'TfNcHLB7'
x77cc33x ()

надо. походу, ближайшие

научиться в типы. hashlib принимает байты, encode возвращает байты, а в replace и после read у тебя строки и не-utf8 данные в файле. Нужно b'...' в replace и open(...,'b') перед read.

Правда, я 3питона ещё не запускал, может всё как-то иначе.

DonkeyHot ★★★★★ ()

все очень просто. внутри своей программы прозрачно оперируем юникодовой строкой. все данные получаемые из внешнего источника (хешлиб, файлы и т.д. ) или получаем как юникодовую строку или раскодируем из байтов в юникодовую строку. все. стало. проще. вместо непонятных преобразований по всему коду, получаем преобразования на точках входов информации. а питон 2 закопайте уже.

anonymous ()
Ответ на: комментарий от anonymous

зачем его закапывать-то?

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

что может быть лучше?

buratino ★★★★★ ()
Ответ на: комментарий от anonymous

Точно та же «аргументация» подходит к i386 ассемблеру.

не подходит. всё дело в решении задач. в эффективном решении задач. это только поверхностным зрением, не разбирая сути, оно *похоже* :)

buratino ★★★★★ ()
Ответ на: комментарий от buratino

питон 2 закопайте

зачем его закапывать-то?

Я вообще питон не очень-то знаю, хотя начинал учить. Ещё когда он только появился, и я прочитал про «фичу», что вместо операторных скобок/бегинов_ендов там отступы - мне это очень не понравилось. Ну и то, что они об обратной совместимости не беспокоятся, в результате на системах стоит сразу по 2 версии питона, потому что одним программам нужна 2-ая, а другим - 3-я.

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

Поэтому, если уж пишешь на питоне, то постепенно надо и самому переходить, и код свой переводить на новые версии. Пока старая работает, спешить некуда, но неспеша двигаться стоит уже сейчас. Иначе через 6 лет может оказаться, что и код твой никому не нужен, потому что проще написать новый с нуля, и ты как специалист застрял в позапрошлом веке и тоже не больно и востребован.

aureliano15 ★★ ()

пытаюсь портировать хоть самые простые вещи на python3

Скажите честно, зачем вам это нужно? :D
Ведь в мире столько интересных ЯПов :]

SysoevDV ()
Ответ на: комментарий от anonymous

Вторая и третья ветка питона - это как C и С++.

Очень странное сравнение версий python-а.
А вообще не важно какой палкой сбивать яблоко с дерева, березовой или дубовой к примеру - все равно результат будет один и тот же.
Это также применимо к выбору ЯПа.

SysoevDV ()
Ответ на: комментарий от anonymous

Вторая и третья ветка питона - это как C и С++.

Зачем тогда людям голову морочить? Назвали бы python и python++, и оба форка развивались бы параллельно. А сейчас получается, что версия 2 как бы устаревшая. А если её обновят, то как будут нумеровать, если 3-й номер уже забит? А если обновлять не собираются, то значит рано или поздно умрёт.

aureliano15 ★★ ()

Питон это говно by design. Вместо Python3 бери вменяемые языки. Затраты будут примерно одинаковые, а может даже меньше.

anonymous ()
Ответ на: комментарий от anonymous

https://www.python.org/downloads/

Спасибо за ссылку. Вижу, что питон 2 всё ещё поддерживается, но всё меньше и меньше (на несколько релизов 3-го питона один 2-ого, последняя версия 2-ого - 2.7.13 от 17.12.2016, последняя версия 3-его - 3.5.4 от 8.8.2017). В общем, пока на 2-ом питоне жить можно и, вероятно, ещё пару-тройку лет он продержится, но дальше с такими тенденциями - вряд ли.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

вероятно, ещё пару-тройку лет он продержится

ЕМНИП официально заявляли о поддержки Python 2 до 2020 года. Дальше - крутитесь как хотите. Так что портировать на Python 3 надо. И начинать лучше тем раньше, чем больше объем кода того, что нужно портировать.

Pinkbyte ★★★★★ ()

2 пайтон уже давно пора закопать, все, что нужно, уже портировано на 3 версию. А с нововведениями версии 3.5 я вообще не вижу смысла использовать 2 ветку.

panter_dsd ★★★★ ()
Ответ на: комментарий от anonymous

последняя версия 3-его - 3.5.4 от 8.8.2017

а предпоследняя версия 3-его - 3.6.2 от 17.07.2017

Кстати, да. :-) Интересная у них нумерация. Похоже, что параллельно поддерживаются не только ветки 2 и 3, но в 3-ей ветке ещё и подветки со 2-ым номером 3.4, 3.5 и 3.6. Получается, что между ними с обратной совместимостью тоже не всё хорошо, иначе зачем было бы их одновременно поддерживать? Странно, что с таким подходом питон вообще всё ещё жив, ведь это должно быть ужасно неудобно и для разрабов и мэйнтейнеров питона (распыляются силы), и для программеров на питоне (всё время что-то меняется, обратной совместимости нет, не успел что-то сделать, как надо уже начинать переделывать), и для конечных пользователей (в общем случае держать 4 версии: 2.7, 3.4, 3.5 и 3.6).

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Ты про минорные фиксы не слышал? Это нормальное явление.

panter_dsd ★★★★ ()

traceback python тебе пишет? Пишет! Так вот не ленись читать его.

anonymous ()
Ответ на: комментарий от aureliano15

последняя версия 2-ого - 2.7.13 от 17.12.2016, последняя версия 3-его - 3.5.4 от 8.8.2017

воот. нафига 3.5.x, если есть 3.6.x? кто помнит различия? а у python2 одна единственная ветка, 2.7, которая была такой же и несколько лет назад, и будет ровно такой же ещё несколько лет

стабильность - признак мастерства :)

buratino ★★★★★ ()
Ответ на: комментарий от Pinkbyte

ЕМНИП официально заявляли о поддержки Python 2 до 2020 года. Дальше - крутитесь как хотите.

желающих поддерживать будет достаточно

помнится, когда похоронили Visual Basic 6, были миллионные петиции. но, во-первых, это закрытый код, а во-вторых, у венды начались масштабные переделки во внешнем виде, которым этот VB6 не соответствовал

а python всё таки более низкоуровневая платформа. поэтому поддерживать её будет проще. так что я не вижу никаких проблем ни после 2020-го года, ни даже после 2030-го.

buratino ★★★★★ ()
Ответ на: комментарий от buratino

желающих поддерживать будет достаточно

Может быть и так, а может и нет.

Когда вышла KDE4, многие тоже говорили о форке 3-й kde, и даже желающие нашлись. И где теперь этот форк?

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

в OpenBSD kde3 до сих пор поддерживается, фиксы накладываются

и причём здесь kde3? на python2 написаны тонны кода, а библиотек там по-прежнему больше, чем для python3. смысл перехода? не вижу ни единой причины перехода. нет желания ни у кого долгими зимними ночами разбираться с новыми байтами и новыми строками. :) проще продолжать пользоваться python2.

buratino ★★★★★ ()
Ответ на: комментарий от aureliano15

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

ну да ладно, скомпилить python2 для себя я всегда смогу. и тонны библиотек тоже в одночасье не исчезнут. :)

buratino ★★★★★ ()
Ответ на: комментарий от buratino

если бы python3 давал реальные стимулы на переход

По мне так проблема в другом: нежелание заботиться об обратной совместимости. Сколько уже существует язык си, и до сих пор без проблем можно собрать программу на си89, а задав специальные опции - и на си k&r. Мне кажется, что они слишком серьёзно восприняли байки о вреде легаси.

скомпилить python2 для себя я всегда смогу.

По хорошему желательно ещё найти и пропатчить потенциальные уязвимости. А кроме того добавить новые библиотеки, которые будут писаться для питон-3. В общем, проблем будет много. Старый код на мёртвом языке м. б. ещё и можно как-то поддерживать, но развивать его в соответствии с новыми веяниями может быть проблематично.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

По мне так проблема в другом: нежелание заботиться об обратной совместимости.

я беру диск с Debian 3.0 2002 года. и спокойно запускаю там всё, что написано для python 2.2

python 3000, который ныне python 3 - это уже другой язык, и он намеренно не был сделан совместимым, чтобы сделать что-то новое

кому не нужно новое - те используют python2, и рады этому

Сколько уже существует язык си, и до сих пор без проблем можно собрать программу на си89, а задав специальные опции - и на си k&r.

ну да, ну да. поэтому в портах чётко задана нужная версия gcc. а с переходом на clang пришлось патчить практически всё, да и то ещё не всё завелось. :) что-то собирается gcc 4.2, что-то - gcc 4.9, что-то - только clang

А кроме того добавить новые библиотеки, которые будут писаться для питон-3

все библиотеки уже есть. а при наличии сообщества (а у python 2 оно многомилионное) - можно написать и для python 2. я вот пишу только для python 2, и судя по этому топику, буду писать ещё долго.

buratino ★★★★★ ()
Ответ на: комментарий от buratino

я беру диск с Debian 3.0 2002 года

Чортовы хипстеры! Есть же slackware 3.3

anonymous ()
Ответ на: комментарий от buratino

Сколько уже существует язык си, и до сих пор без проблем можно собрать программу на си89, а задав специальные опции - и на си k&r.

поэтому в портах чётко задана нужная версия gcc. а с переходом на clang пришлось патчить практически всё, да и то ещё не всё завелось. :) что-то собирается gcc 4.2, что-то - gcc 4.9, что-то - только clang

Не надо путать стандарты си с разными нестандартными расширениями, как то GNU-расширения, API Posix и др. (POSIX - это тоже стандарт, но не для си), а также разные опции компилятора и др. утилит, которые могут быть прописаны в Makefile и меняться от компилятора к компилятору, сами Makefile (стандартный, гнутый и т. д.) и сборочные зависимости, прописываемые майнтейнерами зачастую от балды (типа у меня собралось всё с такой-то версией чего-то, значит её и пропишем, и даже не будем проверять, собирается ли оно с более старой версией).

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

вместо операторных скобок/бегинов_ендов там отступы - мне это очень не понравилось

Если школьника бить линейкой по рукам за кривой почерк - ему это тоже не понравится. Зато понравится тем кто эту писанину потом читать будет

Siado ★★★★★ ()
Ответ на: комментарий от anonymous

все. стало. проще. вместо непонятных преобразований по всему коду

Непонятных преобразований стало наоборот больше.

anonymous ()

Анонимус неодобряет

Парень, ты нормальный? Какой нафиг питон, у тебя base64 какого-то хрена выдал 0x89, хотя должен только ascii выдавать. Ты проверял, может оно и во втором так, только ошибку молча проглатывает?

anonymous ()
Ответ на: комментарий от Siado

вместо операторных скобок/бегинов_ендов там отступы - мне это очень не понравилось

Зато понравится тем кто эту писанину потом читать будет

Ну я же не говорю, что не надо выделять блоки отступами. Но начальные отступы могут быть съедены разными редакторами, заменены на табуляции и т. д. А при просмотре кода с пропорциональным шрифтом их вообще не видно. На возможный вопрос, зачем так просматривать код, сразу отвечу: такое иногда бывает в криво свёрстанных книгах и хтмльках. В общем, считаю, что и для записи, и для чтения куда удобнее и безопаснее поставить в начале и в конце блока фигурные скобки или соответствующие операторы (begin, end, then, fi, do, done, etc), а уже внутри можно (и нужно) и отступы добавить.

Кстати, то, что команды в Makefile должны начинаться именно с табуляции (которую зачастую не отличишь от нескольких пробелов), мне тоже очень не нравится.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Нет. Отступы обязательны. При наличии отступов скобки избыточны. Пихать их туда ради криво форматированых хтмльек - идиотизм.

anonymous ()

если вам так трудно уследить за требуемыми типами самостоятельно, зачем вообще использовать язык с динамическими типами?

anonymous ()
Ответ на: комментарий от anonymous

При наличии отступов скобки избыточны. Пихать их туда ради криво форматированых хтмльек - идиотизм.

Ну, это дело вкуса. М. б. в каком-нибудь сферическом вакууме это действительно идиотизм, а в нашем реальном мире, имхо, совсем нет.

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Ну, это дело вкуса.

Это дело не вкуса, а рациональности. Дай вам волю, вы чексумму в конец каждого файла заставите писать. А что, вдруг в кривой хтмльке что-то сломается, а по чексумме проверить можно.

anonymous ()
Ответ на: комментарий от anonymous

Вторая и третья ветка питона - это как C и С++. Кто из них устаревший?

Оба.

no-such-file ★★★★★ ()
Ответ на: комментарий от anonymous

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

Такое уже есть. Электронной подписью называется. И вполне себе успешно используется. :-)

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Такое уже есть. Электронной подписью называется. И вполне себе успешно используется. :-)

Вот-вот, ты ещё лучше придумал. Встроите в синтаксис языка, что в каждом файле должна быть электронная подписть исходника, иначе компилятор/интерпретатор будет ошибки выкидывать. Всё ради хтмлек, вдруг сломаются.

anonymous ()
Ответ на: комментарий от anonymous

Встроите в синтаксис языка, что в каждом файле должна быть электронная подписть

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

aureliano15 ★★ ()
Ответ на: комментарий от aureliano15

Ну, в синтаксис языка вставлять - это перебор.

Ну вот скобки - это исторически сложившийся перебор.

anonymous ()
Ответ на: комментарий от anonymous

скобки - это исторически сложившийся перебор

Скобки позволяют нормально записывать лямбды и обходится без костылей в виде pass. Но ты главное верь.

no-such-file ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.