Я тут пока пришёл к идеи сделать одно поле-список, в котором записывать все названия декоратора, который навешан на функцию

Я тут пока пришёл к идеи сделать одно поле-список, в котором записывать все названия декоратора, который навешан на функцию

Какую задачу ты хочешь этим решить?

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

Ты их и так можешь помечать декораторами.

ты предлагаешь проверки в декораторах писать?

Приведи лучше пример своей задачи

Пока это выглядит странно

а как она на производительность влияет, сильно?

Влияет, вот я стек из 10 вызовов пробегаю, сто таких операций весьма ощутимо https://ideone.com/E7XxwU

ты предлагаешь проверки в декораторах писать?

Нормальная тема кстати

api-методы где-то нужна идентификация пользователя где-то нужно проверить на валидность определенных параметров где-то нужно привязать доп параметры к методу

+ за проверки в декораторах

Я так делал, ещё можно передавать параметрами что нужно проверять

api-методы где-то нужна идентификация пользователя где-то нужно проверить на валидность определенных параметров где-то нужно привязать доп параметры к методу

А причем тут инспеция имеющихся декораторов?

чтобы я мог свою вьюху пометить, что она нуждается в том, в том и в том

То есть нужен атрибут функции, а не декоратор?

чтобы я мог свою вьюху пометить, что она нуждается в том, в том и в том

Не вижу связи. Ты и так ее можешь пометить.

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

для динамичности системы)

api-методы где-то нужна идентификация пользователя где-то нужно проверить на валидность определенных параметров где-то нужно привязать доп параметры к методу

Выглядит как задача для декораторов или самих вьюх (общее по миксинм распихать) Это не нужно делать в миддлварях, миддлвари для глобального изменения всего

у меня щас это реализовано на наследовании от своего BaseView класса, который от View унаследован + доп миксины

Но так как, мне кажется, лучше использовать декораторы, чем полагаться на множественное наследование python

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

множественное наследование чем не угодило?

хз, чего-то не доверяю я ему, от java всё это идёт и от плюсов) + такие понятия как exploding class hierarchy вызывают неприязнь

Думаете, лучше сделать миксины и всё?

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

чтобы я мог свою вьюху пометить, что она нуждается в том, в том и в том

Оборачиваешь в декоратор и передаешь в вызов функции

Я по максимуму использую декораторы внутри вьюхи на методы уже

для этого в джанге есть method_decorator

хелпер, который помогает обычный декоратор навернуть на метод класса (get, post..)

Но миксины тоже норм

да, я и хочу щас навесить через method_decorator список моих декораторов на class based view

Миксины менее явные и как-то не прижились, а так норм да

Не прижились где?)

В джанге они кругом

https://stackoverflow.com/questions/3232024/introspection-to-get-decorator-names-on-a-method

ну это то же самое, что флажки, просто через один метод как в method_decorator

2й ответ интересный

Миксины менее явные и как-то не прижились, а так норм да

0_0

Только их и используют же. Смысл плодить одинаковый код?

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

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

Вот я тоже к этому хочу стремиться))

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

может тогда их было бы меньше?..

строк кода

нет

Вот я тоже к этому хочу стремиться))

Это не серебряная пуля, всегда нужно понимать зачем ты это делаешь и исходить из этого

Это не серебряная пуля, всегда нужно понимать зачем ты это делаешь и исходить из этого

+ Я к тому, что встречаю cbv в разы чаще fbv

+ Я к тому, что встречаю cbv в разы чаще fbv

у меня cbv

а что такое cbv и fbv?

class/function based view

fbv мне кажется удобней

Холиварная тема

class/function based view

А, ясно, а мне cbv кажется удобней get post явно чётко разделяешь логику, никаких if request.method == 'POST' и т д ))

fbv мне кажется удобней

серьезно? а давай это в fbv преобразуем https://pastebin.com/A4VAV0GE

во, давно холиваров не было

fbv удобней для чего-то не стандартного и когда используется только 1 HTTP метод, например функция смены языка сессии

я не про drf.. там конечно, удобней в cbv.. но для обычного сайта fbv мне кажутся удобными.. к тому-же, если есть насколько форм на странице - это адский ад для классов

я не про drf.. там конечно, удобней в cbv.. но для обычного сайта fbv мне кажутся удобными.. к тому-же, если есть насколько форм на странице - это адский ад для классов

Если не уметь работать с цбв - то все в них будет казаться Вам адом

казалось бы что там уметь

Если не уметь работать с цбв - то все в них будет казаться Вам адом

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

к тому-же

Что это за схема такая чудесная?)

cbv, наследования

без поллитра не разобраться

к тому-же

И что к тому же? Большинство классов через 2 родителя от object.

ERROR: S client not available

без поллитра не разобраться

Не согласен. Все просто и очевидно

Не согласен. Все просто и очевидно

++

Более того, все высшие классы отлично описаны в документации

Более того, все высшие классы отлично описаны в документации

Более того, никто не заставляет использовать что то помимо View

Привет всем! Если мне нужно вытащить модель из первой джанги на темплэйт второй джанги, то как это организовать?

Привет всем! Если мне нужно вытащить модель из первой джанги на темплэйт второй джанги, то как это организовать?

Что такое первая и вторая джанга?

Привет всем! Если мне нужно вытащить модель из первой джанги на темплэйт второй джанги, то как это организовать?

А это как (вытащить модель из первой джанги) из 1.х в 2.0? Хотите переехать на новую версию или что?

В первой хранится информация и апи, вторая поднимает сайт на основе этой информации. Я редактирую захардкоженную страничку сайта

Что такое первая и вторая джанга?

Есть две джанги...

эм, дичь

апи обычно юзают через JS, а не бэк

api - имеется в виду REST?

api - имеется в виду REST?

Я уж собирался возмутиться))

sys.path.append('/path/to/project') потом from appname.models import ModelName может как-то так?

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

Вопрос

Кто нибудь делал как нибудь учёт недель в БД и как нибудь можно в форме даты указывать неделю а не конкретную дату?

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

Ну а я хочу новый год и спать

Кто нибудь делал как нибудь учёт недель в БД и как нибудь можно в форме даты указывать неделю а не конкретную дату?

strptime умеет 2017-W24-1 превратить в "первый день 24 недели 2017 года, неделя начинается с понедельника"

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

Там NullBoleanField не спасёт? Без извращений этих, вот?

Кто нибудь делал как нибудь учёт недель в БД и как нибудь можно в форме даты указывать неделю а не конкретную дату?

я делал определение пн и вс и через фильтры >= < выдергивал нужные записи

strptime умеет 2017-W24-1 превратить в "первый день 24 недели 2017 года, неделя начинается с понедельника"

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

Там NullBoleanField не спасёт? Без извращений этих, вот?

Нет.

strptime умеет 2017-W24-1 превратить в "первый день 24 недели 2017 года, неделя начинается с понедельника"

А конкретно неделю нельзя указывать?

А конкретно неделю нельзя указывать?

"неделя, в которой есть 14 декабря"?

Нет.

Почему? Отгружен, Неотгружен, Хз

Почему? Отгружен, Неотгружен, Хз

Ну он точно отгружается в течении недели.

"неделя, в которой есть 14 декабря"?

НЕт, например как на настенных календарях, например сечас идет 51-ая неделя

НЕт, например как на настенных календарях, например сечас идет 51-ая неделя

»> datetime.datetime.now().strftime("%W") '51'

ну там int() ещё добавить

или >>> datetime.datetime.now().isocalendar()[1] 51 там вроде какая-то разница есть с определением первой недели.