LINUX.ORG.RU

Допустимо ли делать вот такое в методе?

 , ,


1

1

Есть модель-дерево. Некоторым view-ам я отдаю само дерево (метод tree) и там уже с ним работаю, а некоторым сразу форматированный набор списков для вывода в форме (метод choises).

Два вопроса: 1. Насколько приемлемо держать такие методы внутри класса, место ли им тут, или всю возню надо делать во view?

2. _own_tree у меня содержит все дерево и инициализируется при первом вызове метода tree. Каково его время жизни? Мне кажется что делаю не так как надо...

class Division(db.Model, BaseNestedSets):
    __tablename__ = 'divisions'
    id = db.Column(db.Integer, primary_key=True)
    division = db.Column(db.String(255), nullable=False)

    _own_tree = None

    @property
    def tree(self):
        if self._own_tree is None:
            self._own_tree = self.drilldown_tree()
        return self._own_tree

    def _choises_tree(self, tree=None, choices=None):
        if choices is None:
            choices = []
        if tree is not None:
            for division in tree:
                div_id = division['node'].id
                div_level = division['node'].level - 1
                div_name = division['node'].division
                choices.append([
                    div_id,
                    ''.join(('\xa0' * div_level, div_name))
                ])
                if 'children' in division:
                    self._choises_tree(division['children'], choices)
        return choices

    @property
    def choises(self):
        return self._choises_tree(self.tree)

cast foozzi

★★★★★

Последнее исправление: Turbid (всего исправлений: 3)

'<Division> %r' % self.division

за такое по рукам бить надо. str.format() и f-строки для кого придуманы?

Насколько приемлемо держать такие методы внутри класса, место ли им тут, или всю возню надо делать во view?

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

Каково его время жизни? Мне кажется что делаю не так как надо

Такое же, как и время жизни самого объекта модели, очевидно. Сам решай, как тебе надо.

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

А помните ли вы с какой версии python поддерживает f-string? Вот мой debian 8 с последним «стабильным» Python(3.5) не поддерживает. Мне это не нравиться, но поделать ничего не могу(сервер то рабочий, просто так обновить никто не даст)

Andreezy
()

Вроде всё выглядит норм.

ei-grad ★★★★★
()
Ответ на: комментарий от eternal_sorrow

за такое по рукам бить надо

ну ок, перевел на f-string

Такое же, как и время жизни самого объекта модели, очевидно.

меня беспокоит то, что каждый инстанс модели будет у себя хранить _own_tree, не оверхед разве? Не лучше ли считать его только по мере запросов из view?

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

каждый инстанс модели будет у себя хранить _own_tree, не оверхед разве

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

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

А докер для кого придуман?

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

deep-purple ★★★★★
()
Ответ на: комментарий от eternal_sorrow

за такое по рукам бить надо. str.format() и f-строки для кого придуманы?

И для чего тут format или f-строки, которых еще ни в один продакшн-дистр не завезли? Или вы уже переписали тот же logging и % можно смело выкидывать из языка?

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

Пускай питон из докера, а приложуху прокидывай внутрь контейнера.

Чай не JS, тут можно не использовать фичи только ради того, чтобы их использовать.

oldstable
()
Ответ на: комментарий от deep-purple

Какой оверхед? Докер работает за счет ядра линукс и изоляций, встроенных в ядро. Там весь оверхед как ты говоришь - это закачка zip и распаковка из него git репы. И всё, вся суть докера.

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

Не спорю на счет format, но мне интересно почему за код ТСа "такое по рукам бить надо", то есть почему так ужасно использовать % в данном конкретном случае. inb4: format "делает код читабельнее"

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

Я про современный подход к проектировке архитектуры, а не про важную преважную фичу f strings.

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

за такое по рукам бить надо

почему?

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

Докер работает за счет ядра линукс и изоляций, встроенных в ядро

Докер — не ядро, а обертка использующая возможности ядра. Вот обертка и есть оверхед.

deep-purple ★★★★★
()
Ответ на: комментарий от Turbid

Хорошо, согласие, что любая обертка привносит оверхед — имеется. Но, почему вопрос про циферки адресован ко мне? Циферки должны быть у тех, кто эти обёртки писал.

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