Python-сообщество

Marta
Возможно, вы правы и упоминать понятие конструктора в рамках Python может быть не корректно. Однако __new__() же возвращает объект класса, а __init__() его инициализирует (настраивает) - вполне себе тот же __construct из того же PHP (да и в других языках нечто подобное). Методов есть много, вплоть до перегрузки операторов при их применение к данному классу.

Не возможно, а 100% прав. В качестве конструкторов выступают два специальных метода класса и понятия конструктора в питоне, как бы не было печально, все же нет. Ну а терминология других языков, в частности ПХП меня не интересует вовсе Потому как я не додумаюсь никогда в питоне называть методы класса “переменными-членами”…

4kpt_IV
Считайте это просто способом упаковки роутов к вьюхам. Нет никакой логической связи между блупринтом и базами…

Я понимаю, что Blueprint по сути добавит новые роуты в созданное Flask-приложение. И дефолтно фреймворк не поднимает вопрос об использовании БД (это уже решает программист сам или с помощью готовых расширений).

4kpt_IV
Ну и зачем два блупринта на один домен я так и не понял

Просто я пытаюсь построить все так, чтобы написать один раз какой-то функционал (пусть будут статьи), а далее просто в конфиге указывать где его подключить (например, на example.org/, example2.org/articles_1/, example2.org/articles_2/).

По факту немного измененный Blueprint (да, я согласна, что мой хардкод диковат и можно переопределить другие места. но чем так плохо и как сделать лучше? что у Blueprint, что у Flask-Classy есть возможность указания subdomain, но возможности указания host - нет, это я ввела просто захардкодив в декораторе route…) и включение host matching дает это сделать в одном приложении (да, разделение чисто за счет роутов, вьюхи остаются одни и те же. знаю, что можно сделать application dispatching и завести по приложению на каждый домен, но пока масштабирования не предвидится, так что не нахожу смысла в этом).

4kpt_IV
У меня возникает ощущение, что Вы пытаетесь решить три проблемы одним шагом. Это совершенно неверно. Такого решения нет.

Хорошо, давайте по шагам. Просто вопрос про модели вылился в обсуждение архитектуры приложения ИМХО. Правда я не могу насчитать три проблемы, вижу две: роутинг и модели. И с моей точки зрения пока все больше упирается в том, что я пока не до конца понимаю внутренности SQLAlchemy (есть peewee, но она уж через чур простая).

4kpt_IV
Хотя мог бы посоветовать тогда собирать свои модели под конкретный блупринт (через подмену Basе) и подсовывать их ему через DI, но у Вас и так в голове сейчас каша, поэтому откланиваюсь

Если вы не против продолжать обсуждение, то мне хотелось бы услышать подробнее на счет этого (использовать паттерн DI - это интересный путь), ну и разобраться и убрать “кашу” (я не просто так пришла на форум сказать, что переопределила пару методов у Blueprint, накопировала python-пакеты с ними и все ОК. а мне интересно разобраться в своих ошибках и понять как сделать лучше и узнать больше ).

4kpt_IV
Не возможно, а 100% прав. В качестве конструкторов выступают два специальных метода класса и понятия конструктора в питоне, как бы не было печально, все же нет. Ну а терминология других языков, в частности ПХП меня не интересует вовсе Потому как я не додумаюсь никогда в питоне называть методы класса “переменными-членами”…

Хорошо. Постараюсь выражаться, так сказать, более в Pythonic way.

Отредактировано Marta (Май 6, 2016 02:59:46)

Так а 4kpt Вам указал вполне нормальное решение - хранить в таблице идентификатор домена. Можно даже тупо хранить строку с именем домена.

ayb
Так а 4kpt Вам указал вполне нормальное решение - хранить в таблице идентификатор домена.

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