Просто, скажем, в __eq__ такой штуки нет. Только для __contains__.

Можно выстрелить в ногу. Но только если не думать изначально о том, что в этой функции надо возвращать бул

Как можно без знания django понять, что происходит?

Легко, если ты примерно представляешь себе, на каких паттернах выстроен джанго

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

Как можно без знания django понять, что происходит?

а это и есть главный недостаток фреймворков

Легко, если ты примерно представляешь себе, на каких паттернах выстроен джанго

urlpatterns = [ path('about/', TemplateView.as_view(template_name="about.html")), ]

Как можно без знания django понять, что происходит?

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

Вот вы строите свой проект на django

это фиаско, братан

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

но при этом если он тебе кажется хорошим, это тоже не очень хорошие новости 8)

но при этом если он тебе кажется хорошим, это тоже не очень хорошие новости 8)

это еще хуже.

Вот торнаду придется почитать чуть подольше, там свои ивент-лупы и всякое такое

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

Ну, самый простой вариант. Что произойдет в django, если клиент прервет запрос?

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

Ну, самый простой вариант. Что произойдет в django, если клиент прервет запрос?

Его nginx отпиздит

Его nginx отпиздит

Ну, а в джанге то что будет?

Про __contains__ даже репортили, оказывается https://bugs.python.org/issue16011

к сожалению, есть немалое количество программистов, что стремятся писать в perl-style

Ну, а в джанге то что будет?

А до джанги не дойдет

Ну, самый простой вариант. Что произойдет в django, если клиент прервет запрос?

Клиент не может прервать свой запрос, джанге пофигу вообще, она пока не выполнит start_response, ответа никакого не последует

Ну, самый простой вариант. Что произойдет в django, если клиент прервет запрос?

что такое "прервет запрос"?

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

"Клиент не может прервать запрос" - это неправильный ответ. Может.

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

Это значит, что джанга думает долго. Она что-то вернет и забудет

Ну ничего не будет, джанга ответит проксирующему nginx, nginx скажет сорян - отвечать некому

А если напрямую django?

А если напрямую django?

Вернет апп серверу, апп сервер ругнется

А если напрямую django?

напрямую нельзя, это django, нужен wsgi-сервер и http-сервер

"Клиент не может прервать запрос" - это неправильный ответ. Может.

он может быть совершенно разным образом выглядеть на сервере. например, клиент тупо отвалился и rst в сторону сервера не долетел.

напрямую нельзя, это django, нужен wsgi-сервер и http-сервер

+много

Никак, сделай ее полем или верни из функции

Кто работал с движком шаблонов Jinja2, можно ли в нём разрешить использовать только выбранные теги, допустим {% for %} {% block %} {% extend %}, и никаких других тегов и фильтров.

self.add_to_cart

Кто работал с движком шаблонов Jinja2, можно ли в нём разрешить использовать только выбранные теги, допустим {% for %} {% block %} {% extend %}, и никаких других тегов и фильтров.

Нет

можно запретить их использовать тем что просто их не использовать)

Кто работал с движком шаблонов Jinja2, можно ли в нём разрешить использовать только выбранные теги, допустим {% for %} {% block %} {% extend %}, и никаких других тегов и фильтров.

Регуляркой пробежаться или парсер пропатчить

патчить парсер жинжи - это самоубийство

Да ладно, от пары декораторов еще никто не умирал

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

можно запретить их использовать тем что просто их не использовать)

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

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

Ну неправда

Ну, декораторы не входят в те 10%, их еще надо раскурить.

Я видел людей, которые не очень разбираются в том, как они работают.

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

Сделай свой язык, транслирующийся в jinja

Ну в устройстве динамических массивов тоже не все разбираются

Я видел людей, которые не очень разбираются в том, как они работают.

Это не проблема декораторов

Я видел людей, которые не очень разбираются в том, как они работают.

Это их проблемы

Есть грань как бы

self.add_to_cart

Спасибо! делал self только на 22 строке,а нужно было ещё на 18

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

Ты это сам придумал?

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

Ты не из пыхи пришел?)

Демагогия какая-то

Разве тут не так написано?

Ну конкретно твой пример довольно простой. Но вообще да, чем меньшему числу разработчиков знакома фишка, тем меньше стоит свеч её использование.

Декораторы это довольно базовая фича языка, ее грешно не знать

Способность отличить, что выкинуть, а что оставить, чтобы максимизировать пользу, является профессиональным навыком хорошего разработчика)

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

Супер-оптимизации по необходимости их наличия оборачиваются в красивый доступный api, если такового нет и какие-то странные ручки торчат из кода - это плохой код и требует, чтобы его переписали

Ну, и какие-то фишки языка позволяют вам сделать такой красивый API, но вот как это сделать, если вы вроде как опытный, но про фишечки то не знаете?

Не надо делать красивый API. Надо делать простой API.

?

А то обмажутся своим Django ORM и пойдут делать красивые API, об которые потом ногу сломишь.

Ну, вот просто так сделать к сложной вещи простой API довольно сложно. Потому что и нужные красивые, что бы за ними спрятать сложность.

В django orm красивый апи, если сравнивать с некоторыми

Ужасный у него api, если сравнивать с алхимией

Энивей. Если ты способен сделать django orm, это не значит, что ты крутой синьор. А если не способен, не значит, что не крутой синьор. Это просто одна специфическая задача.

Типичная language-specific задача, кстати.

У вас есть другие задачи?

В го до сих пор не сделали нормальный орм, ничего, живем, синьорством обрастаем

language-agnostic задачи?)

В го до сих пор не сделали нормальный орм, ничего, живем, синьорством обрастаем

Сложно сделать нормальный орм без дженериков и нормальной интроспекции

У вас есть другие задачи?

У нас есть бизнес-задачи, за которые платят, и мы пишем на чистом sql частично с билдером, где требуется

Ну вообще-то да

У нас есть бизнес-задачи, за которые платят, и мы пишем на чистом sql частично с билдером, где требуется

Ну, они же привязаны в sql, причем к определенному диалекту, разве нет?

Ну вообще-то да

Ну, вот вы каждую задачу решаете с language-agnostic подходом или все-таки на каком-то языке программирования, причем определенном еще на начале задачи?

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

Ну, вот вы каждую задачу решаете с language-agnostic подходом или все-таки на каком-то языке программирования, причем определенном еще на начале задачи?

а кто мешает сначала попробовать на чем-то одном на коленке, а потом переписать на другом?

Ну, они же привязаны в sql, причем к определенному диалекту, разве нет?

Привязанность к диалекту устраняется одним слоем абстракции.

Также микросервисы, в каноничном их представлении, которые можно за 2 недели переписать

Ну, вот вы каждую задачу решаете с language-agnostic подходом или все-таки на каком-то языке программирования, причем определенном еще на начале задачи?

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

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

Каким образом он должен поменяться от смены языка?

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

Ну, то есть вы абстракции, которые используете в проекте транслируете в language-agnostic в голове, придумываете решение и потом обратно в язык парсите?

Ну, то есть вы абстракции, которые используете в проекте транслируете в language-agnostic в голове, придумываете решение и потом обратно в язык парсите?

И?

Каким образом он должен поменяться от смены языка?

Самый простой пример, в языке X имеет смысл заниматся распаралеливанием задачи, в языке Y уже не особо.

Самый простой пример, в языке X имеет смысл заниматся распаралеливанием задачи, в языке Y уже не особо.

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

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

Разве, например, в python распараллеливание не дороже, чем в c, потому что в первом вы можете использовать только распараллеливание через процессы, так как в первом можно использовать потоки и шаринг общей памяти? И не может быть такого, что из-за перехода с С на python распараллеливание станет бессмысленным?

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

Я не понимаю, о чём этот спор. Да, мы учитываем конкретный язык при решении задачи. Нет, язык не являются решающим фактором в чём-либо.

Разве, например, в python распараллеливание не дороже, чем в c, потому что в первом вы можете использовать только распараллеливание через процессы, так как в первом можно использовать потоки и шаринг общей памяти? И не может быть такого, что из-за перехода с С на python распараллеливание станет бессмысленным?

Для начала я бы не стал изначально делать на потоках и общем состоянии, это плохой паттерн, который требует бесконечное время на отладку race condition. Взял бы и сделал cqrs реализацию, можно даже на питоне воркеров нацеплять и на любом другом языке

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

>я просто вычеркну питон чому так строго? а чоб не сделать stateless и параллелить инстансами и управлять всем через куб?

>я просто вычеркну питон чому так строго? а чоб не сделать stateless и параллелить инстансами и управлять всем через куб?

Звучит сложновато! Ну окей, переставлю питон в конец списка по приоритету.