Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Питон - просто капец
Форум на CrossPlatform.RU > Разработка > Интерпретируемые языки
Litkevich Yuriy
у меня уже сложилось стойкое впечатление, что Питон писал голандец, для которого доступ у наркоте такой-же как у нас к сигаретам.
Делаю сайт на Джанге (1.5 / Питон 2.7)
сделал логер
mylogger.py

# -*- coding: utf-8 -*-

import os

LOG_FILE_NAME = os.path.dirname(__file__) + '/logs/my.log'
LOG_FILE_NAME = LOG_FILE_NAME.replace('\\','/')

print 'LOG_FILE_NAME = ', LOG_FILE_NAME

def write(string):
    try:
        f = open(LOG_FILE_NAME, 'a')
    except:
        f = open(LOG_FILE_NAME, 'w')
    f.write(string)
    f.write('\n')
    f.close()



Решил использовать:
Раскрывающийся текст

# -*- coding: utf-8 -*-

import mylogger as Log
...
def getImageOrDummy(image = None):
    Log.write('getImageOrDummy')
    ...
    Log.write('Привет-1')
    Log.write(u'Привет-2')
    if exists:
        return image
    ...
третья строка в лог не печатается, ошибок нет. Хер бы с ней, но на сайте пропали картинки. Если третью строку закомментировать, то картинки появляются опять.

Порвал бы нарка :ireful:
Iron Bug
надо просто документацию читать.
для записи юникода в файл нужно использовать перекодирование строки в юникод: encode('utf8').
когда скрипт обламывается, загрузка страницы тоже обламывается. так что последствия могут быт какие угодно.
Litkevich Yuriy
Цитата(Iron Bug @ 27.3.2014, 11:21) *
нужно использовать перекодирование строки в юникод: encode('utf8').
пробовано, универсально не работает, на виндавозе работает, а после выкладывания на хостинг - фик.

Вообще питон и кодировки - засада. Вменяемо сделать нарк не мог. Поэтому пол интернета - один вопросы с кодировками.
В тойже Qt есть класс QString, который всё разруливает.

Сегодня потратил день на следующий код:
Раскрывающийся текст

def build():
    #   обработаем все файлы
    for root, dirs, files in os.walk(SOURCE_DIR):
        for file in files:
            src = os.path.join(SOURCE_DIR, file)
            dest = os.path.join(TARGET_DIR, file)
            destpath = os.path.dirname(dest)
            #   если целевого каталога нет - создадим его
            if not os.path.exists(destpath):
                os.makedirs(destpath)
            # Собственно копирование файла
            shutil.copyfile(src, dest)
            # Сохраним запись в БД
            i = Image2(original_name = file.decode('cp1251'),
                       filename = os.path.basename(dest))
            i.save()

В БД не сохранялось из-за кодировок, долго не мог врубится, что нужно добавить decode('cp1251'). В Qt мне такой финт ушами не нужен, я просто передаю имя файла в качестве значения поля original_name и всё. Т.к. Qt сама знает в какой кодировке имена в ФС на данной ОСьке.

Щас вот думаю, как сделать, чтобы у меня и на винде и на лине этот код работал.
Iron Bug
дело не в питоне. тут у тебя уже где-то не стоят кодировки или ещё что-то, нужное ему для перекодирования. читай логи, проверь, что у тебя вообще стоит UTF-8 в системе.
Litkevich Yuriy
На хостинге может стоять любая системная кодировка и koi8-r в том числе. И совсем не дело всё это в коде разруливать, тем более что есть ещё и сторонние пакеты.
Iron Bug
во-первых, хостинг всегда предоставляет информацию о том, что у них установлено. во-вторых, к системной кодировке этот вопрос вообще отношения не имеет. но если это публичный хостинг, то вряд ли там есть проблемы с неустановленными кодировками.
видишь ли, ты ковыряешь вещи, которые не знаешь. работаешь с сервером, настроек которого ты не спрашивал. пытаешься писать на языке, правил которого ты не читал. и выдвигаешь претензии, что все вокруг виноваты. как-то так получается.
люди пишут на Питоне дофига всего, никто не жалуется. может, надо начать с Hello,World и разобраться с языком, прежде чем переходить к правке чужого кода?
тем более, не стоит делать таких вещей с рабочими, а не тестовыми сайтами.
Litkevich Yuriy
Цитата(Iron Bug @ 29.3.2014, 14:09) *
прежде чем переходить к правке чужого кода?
я весь сайт с нуля сделал :)
А жопа с кодировкой так и осталась. Пока методом научного тыка подобрал какую-то комбинацию string.enode("FOO").decode("BAR") и преобразовал имена всех ранее загруженных файлов MD5, информацию об оригинальном имени храню в БД.
Теперь при загрузке на сервер все файлы так переименовываю.

Вообще критинизм заключается в выбросе исключений при преобразовании кодировок.
Представь себе текстовый редактор (например, редактор кода в IDE) который падает, если кодировка файла для него оказалась не понятной.


Цитата(Iron Bug @ 29.3.2014, 14:09) *
люди пишут на Питоне дофига всего, никто не жалуется
им не вдомёк, что кроме английского существуют другие языки, в частности один из сторонних модулей джанги усиленно использовал не Юникод-константы, т.е.
str = 'foo'
вместо
str =u'foo'

а потом к ни прибавлялись имена файлов с русскими буквами и происходило исключение.
Iron Bug
я бы не советовала использовать не-юникод на сайтах. потому что юникод есть везде, а вот всякие кривые кодировки вроде cp1251 - это под большим вопросом.
тут дело даже не в том, "русские" это буквы или нет. а в том, что у тебя есть конкретный редактор и в самом коде буквы могут быть кривые, типа cp1251, а юниксовые сервера обычно про них ничего не знают.
в общем, лучше использовать юникод. там хоть английский, хоть русский, хоть китайский. и никаких проблем.
Litkevich Yuriy
В этом-то и беда, что в питоне, пусть по историческим причинам, есть два типа строк.
А дорабатывать этот чужой модуль я не рискнул, т.к. он сложен для меня.
И ещё некоторые функции питона пытаются определить тип строки ковыряя питоно-потраха самой строки, при этом чаще всего и происходят исключения, т.к. они оперируют жёсткими таблицами перекодировки.
По этому я и сравнил с Qt, в которой есть QString и только через него вся работа идёт (есть конечно и сырая строка - QByteArray, но с ней меньше сталкиваешься).

Одно могу сказать с уверенностью: выкидывание исключений при преобразовании кодировок - зло.

П.С. в тестовом режиме запустил: http://стрекоза-тюмень.рф/catalog
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.