\u043f\u0440\u0438\u0432\u0435\u0442

чувак

это обычный жаваскрипт литерал

в котором юникодные символы эскейпами. в питоне точно такой же синтаксис

ясно. а как это раскодировать правильно?

это и есть уже правильная кодировка строк в жсон

если ты на строку смотришь из питона, то по дефолту он пропускает через sys.displayhook, который по дефолту пропускает это через репр

ладно, как мне разобрать этот жсон чтобы получить кириллицу в логе

>>> u'\u0431\u043b\u044f\u0434\u044c' u'\u0431\u043b\u044f\u0434\u044c' >>> print(u'\u0431\u043b\u044f\u0434\u044c') блядь

ясно. а как это раскодировать правильно?

json.dump(users, f, ensure_ascii=False) Это если ты сам записываешь json

не

это не я записываю

я читаю

если ты суешь весь объект - то получишь в логах репр

да меня и строка устраивает

который во втором питоне будет пытаться перегнать всё в аскии и будет писать в такой нотации

log.debug('got text from %s: %s', response.json['result']['from']['username'], response.json['result']['text'])

второй питон так же кодирует юникод объекты в утф8 по дефолту если чо

странно

str.decode не срабатывает на этой строке

т.е. logging.basicConfig(filename='out.log', ...) log.debug(u'кириллица: %s', u'тест')

а почему он должен работать на юникоде?

ладно, короче json.loads декодирует, да и ладно

123

json.loads 1) по дефолту считает что файл в утф8 2) читает и парсит его аналогично жскрипту, читая строки в утф и декодируя их из литералов в родные питоновые юникодные строки 3) декод ясен пень работать не будет, так как тебе уже прилетел полностью десериализованный вариант

Ребята? Где почитать про парсинг модулей? Я хочу достучатся к файлу который лежит дерикторией выше, но не в $PATH и не в той же папке

эм

Модуль os

ты хуйню хочешь

Или сис пас.

"достучаться" - это что?

import script

Импортировать некие функции с него

у тебя скрипт запущен в каталоге

и ты хочешь именно импортировать то, что каталогом выше?

Да

и под каким именем?

Возможно даже на два или три каталога выше

и под каким именем?

Всмысле?

в питоне импорты не работают с файлами и каталогами

а с модулями и пакаджами. которые могут не иметь отношения к файловой системе вообще

Хорошо, а тут пишет - the directory containing the input script (or the current directory). - PYTHONPATH (a list of directory names, with the same syntax as the shell variable PATH). - the installation-dependent default.

The Module Search Path

и?

это не список поиска инклудов как во всяких пхп

sys.path.insert(0,"lib")

марк, пройди нахуй с этими советами, пазазя

Нормальные советы.

нет

Всё ровно работает. Не пизди

изза таких вот "sys.path.insert" джангоёбы ебались несколько лет

всё?

бгыгыгы

А причем тут джанго?

а она тоже делала именно это

Я не шарю в пхп Просто если модуль который я хочу импортнуть а) в папке .getcwd(), б) в папке для модулей питона - то выйдет

совала в патх одновременно каталог проекта и пакаджа в нем

У меня вот в тестах подключение либ идет. И норм

А если модуль выше будет, то как оно его найдет?

Я не шарю в пхп Просто если модуль который я хочу импортнуть а) в папке .getcwd(), б) в папке для модулей питона - то выйдет

у тебя подход кривой изначально

у тебя подход кривой изначально

Согласен, в архитектуре не шарю

У меня вот в тестах подключение либ идет. И норм

так можно, да. но понимать при этом что происходит

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

sys.path содержит список каталогов когда мы делаем import foo.bar.baz то происходит пачка импортов по цепочке

скажем у нас есть sys.path=['/python/lib', '/python/lib/site-packages']

сперва импортируется foo - для этого питон проходит по sys.path и ищет /python/lib/foo/__init__.py /python/lib/foo.py /python/lib/site-packages/foo/__init__.py /python/lib/site-packages/foo.py

в /python/lib обычно находятся стандартные модули как os.py, sqlite3/__init__.py, и т.п.

ERROR: S client not available

в сайт-пакаджи обычно пип ставит пакеты и они находятся там

теперь есть один нюанс. когда питоном запускается скрипт, в начало сис.патх вставляется '' строка, которая значит "каталог скрипта"

А если модуль выше будет, то как оно его найдет?

модуль выше ищется по такой схеме - ../../ два раза вверх

т.е. у нас есть script1.py, script2.py где в script1 стоит строка import script2 python script1.py - начнет искать с каталога скрипта и загрузит скрипт2 как модуль

модуль выше ищется по такой схеме - ../../ два раза вверх

ищется кем?

модуль выше ищется по такой схеме - ../../ два раза вверх

Но его нет в sys.path изначально. У меня косяк в архитектуре

А инсертить - зашквар

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

теперь почему я спросил про имя в самом начале

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

Хорошо, спасибо за объяснения. Можно вопросик про архитектуру приложения?

ок, мы послушаем марка и сделаем sys.path.insert(0, '..')

Хорошо, спасибо за объяснения. Можно вопросик про архитектуру приложения?

в линухе работает

и сделаем import name (без .py разумеется)

и он таки его найдет, да

|script.py |under/ |----second-script.py Как из second-script.py достучатся до script.py как к модулю? Парсер модулей увидит script.py из second-script?

а еще у нас import under.secondscript начнет работать

думаю понятно что на имена файлов, которые не имеют валидного имени идентификатора (как second-script) это не прокатит

но вот возможность случайно заимпортить чтото лишнее появляется

конкретно в этом случае шансы малы

конкретно в джанге, на этом спотыкались все подряд, включая саму джангу

они эту хуйню делали чтобы упростить людям импорт настроек типа что оно работало и по import project.settings и import settings

для этого каталог пакаджа проекта совался в sys.path

ок, мы послушаем марка и сделаем sys.path.insert(0, '..')

По тестам будет всё ровно

но есть маааааленькая проблема. для каждого имени создавался свой объект-модуль с копией и если кому-то хотелось менять настройки на лету меняя переменную в сеттингс - одна из копий не обновлялась

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

если необходимо запускать произвольное питоноговно откуда попало, то есть несколько способов

есть еще вариант перейти выше по директории через апи вызовы командной строки cd ..

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

другой вариант - загружать код без механизма импортов через другие методы

Вообщем: |plugins/ | plugin_name/ | main.py |main_functional.py Это изначальная архитектура, пользователь запускает main.py в папке какого-то плагина, этот main.py делает магию и общается с main_functional.py. Скорее всего довольно косячная архитектура, ибо кроме импортов есть косяк - пользователь будет запускать, искать плагины отдельно. Я думал переделать в вот такое: |plugins/ | plugin_name/ | __init__.py | main.py |main_functional.py |launch_this.py Где пользователь запустит launch_this.py, он спарсит все плагины, в __init__.py будет какая-то информация для отображения в launch_this.py, вообщем после нахождения всех плагинов отобразит что-то типо: Найденные плагины: 1. plugin_name Выберите номер нужного плагина: После выбора номнра плагина отобразятся input() с плагина, и теперь работа будет происходить только с плагином Вот только как это все грамотно сделать

например execfile/exec, либо runpy.run_module

дерьмовая какая-то схема, где всё с ног на голову

А я про вторую