Ну может декораторы и не совсем правильное название, но они делают дело, да и не я их называл. Так что аргумент не принимается.
Что же качается return и raise, то где вы увидели SomeCustomError()? А использование исключений позволяет выносить отдельные вещи в подфункции, декораторы и возвращать {«success»: true} просто по успешному завершению функции. В остальном же дело вкуса и спорить об этом глупо.
Связность есть — мелкие нужные штуки, слабая, конечно, но поддерживать кучу пакетов, а соответственно привносить кучу сущностей — тоже сомнительное решение.
Ну структурном программировании можно долго спорить, я не считаю его такой уж безусловно правильной идеей. По мне, код должен отражать, то как удобно думать о решении, и если удобней думать «если так, то сразу выкидываем, если сяк, то выводим сообщение, а иначе — обычная обработка», то и код должен выглядеть именно так.
Каждый раз когда мы не выходим из функции сразу, мы вынуждены вводить новый элемент состояния (переменную/флажок), который занимает внимание, читающего такой код, программиста, а это весьма ограниченный ресурс.
Никто не запрещает, но мне удобно думать, что у меня отдельно есть обработчик бизнес логики, а отдельно другие аспекты — контроль доступа, обработка ошибок и представление. То, что я могу их отделить — однозначно хорошо, как это делать в виде утилит и шорткатов, которые вызываются по мере надобности, в виде композиции функций с использованием синтаксиса декораторов или с помощью наследования классов дело вкуса.
P.S. Можно использовать <source lang="python">...</source> для подстветки кода и @ для создания собак.
Я думал об этом, но в конце концов не стал реализовывать, это усложнит реализацию и сделает поведение не таким очевидным, стоит ли оно того, чтобы не писать пары скобок?
Ну в 9.1, вроде, добавили перестройку плана при получении реальных параметров, но я не вижу где тут можно много времени выиграть — парсинг запроса не такая уж сложная вещь.
Примерно так — пришедший запрос парсится в какое-то внутреннее представление, потом для него готовится план выполнения. При составлении плана могут использоваться значения в условиях, например, если какое-то условие выберет небольшое количество рядов (по прогнозам), то будет использоваться соответствующий индекс, если много, то просто последовательное сканирование.
Когда запустит тогда и будем смотреть, и адекватно отвечать. Решать проблему до её возникновения в корне неверно. А если просто ловить все такие ошибки, то это может привести к замалчиванию неправильного поведения, битых ссылок и т.п.
Опыт показывает, что при замалчивании ошибок искать такие проколы по жалобам пользователей довольно сложно и небыстро.
Вопрос восприятия, у нас концепция такова, что 500я должна выдаваться если произошло что-то неожиданное, что не было предусмотрено. И одновременно уходит письмо разработчикам. Такой подход позволяет быстро находить и чинить многие баги.
1. Один из вариантов декораторов — это композиция, и естественно они будут менять семантику декорируемой функции. foo здесь уже не вьюха, а только её часть и если думать о ней так, то вполне логично, что и выглядит она по другому.
2. Такой проблемы не возникало, а следовательно и решать её преждевременно.
4. console.EmailBackend выводит на консоль уже кодированное письмо, т.е. русский текст не прочитаешь. Решение конечно ad-hoc, правильнее было бы свой EmailBackend написать.
И если у тебя несколько выходов из вьюхи, то придётся имя шаблона повторять, либо вынести в переменную. Так что всё спорно.
Это просто другой способ смотреть на вещи — отдельно логика, отдельно рендеринг. Кроме того, @render_to() предлагает более высокий уровень факторизации, например похожие страницы для зарегистрированных и для анонимов могут использовать общую логику:
def _edit(request):
# логика редактирования какой-нибудь штуки
# будет использоваться повторно
# создаём вьюхи из логики и других аспектов
my_edit = login_required(render_to('my/edit.html')(_edit))
edit = render_to()(_edit)
Что же качается return и raise, то где вы увидели SomeCustomError()? А использование исключений позволяет выносить отдельные вещи в подфункции, декораторы и возвращать {«success»: true} просто по успешному завершению функции. В остальном же дело вкуса и спорить об этом глупо.
Каждый раз когда мы не выходим из функции сразу, мы вынуждены вводить новый элемент состояния (переменную/флажок), который занимает внимание, читающего такой код, программиста, а это весьма ограниченный ресурс.
P.S. Можно использовать
<source lang="python">...</source>для подстветки кода и@для создания собак.import *как раз стандартная практика в джанго.Да и большинство юзкейсов покрывают INSERT… VALUES… и UPDATE… VALUES…
wiki.postgresql.org/wiki/FAQ#Why_is_my_query_much_slower_when_run_as_a_prepared_query.3F
В MySQL возможно планирование попроще и выиграть на подготовленных запросах действительно можно.
Опыт показывает, что при замалчивании ошибок искать такие проколы по жалобам пользователей довольно сложно и небыстро.
render(), конечно, уменьшает надобность в@render_to().fooздесь уже не вьюха, а только её часть и если думать о ней так, то вполне логично, что и выглядит она по другому.2. Такой проблемы не возникало, а следовательно и решать её преждевременно.
4. console.EmailBackend выводит на консоль уже кодированное письмо, т.е. русский текст не прочитаешь. Решение конечно ad-hoc, правильнее было бы свой EmailBackend написать.
Это просто другой способ смотреть на вещи — отдельно логика, отдельно рендеринг. Кроме того,
@render_to()предлагает более высокий уровень факторизации, например похожие страницы для зарегистрированных и для анонимов могут использовать общую логику: