Рассуждения о синтаксисе Python (почему бы не воспользоваться. Как это делает синтаксис шаблона django?)

Question

Мой инструктор по каратэ любит говорить: «Блок - это замок, это бросок - это удар». Он имеет в виду следующее: когда мы подходим к технике в форме, хотя она может показаться похожей на блок, небольшое творчество и осмотр показывают, что ее также можно рассматривать как некий замок сустава или какой-то бросок или какой-то удар.

То же самое относится и к тому, как синтаксис шаблона django использует символ точки ("."). Сначала он воспринимает это как поиск по словарю, но также будет рассматривать его как атрибут класса, метод или индекс списка - в этом порядке. Предполагается, что, так или иначе, мы ищем знания. Какие бы средства ни использовались для хранения этих знаний, мы будем обращаться с ними таким образом, чтобы включить их в шаблон.

Почему Python не делает то же самое? Если есть случай, когда я мог бы присвоить словарному термину спам ['eggs'], но точно знаю, что спам имеет атрибут eggs, почему бы не дать мне просто написать spam.eggs и разобраться как делают шаблоны django?

В противном случае мне нужно исключить AttributeError и добавить три дополнительные строки кода.

Меня особенно интересует философия, которая управляет этой настройкой. Считается ли это частью строгой типизации?

Answer 1

шаблоны django и python - это два не связанных между собой языка. У них также есть различные целевые аудитории.

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

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

Answer 2

ПРОСТО МОЕ правильное МНЕНИЕ действительно правильное мнение. Я не могу сказать, почему Гвидо сделал это так, но я могу сказать, почему я рад, что он сделал.

1. Я могу посмотреть на код и сразу узнать , если какое-то выражение обращается к клавише 'b' в объекте, похожем на диктовку a, атрибут 'b' на объекте a, вызываемый метод или индекс b в последовательности a.

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

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

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

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

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

Answer 3

В дополнение к ответам, приведенным выше, нецелесообразно объединять поиск по словарю и поиск объектов в целом из-за ограничений на элементы объекта.

Что если у вашего ключа есть пробел? Что делать, если это int или frozenset и т. Д.? Точечная запись не может объяснить эти несоответствия, поэтому, хотя это приемлемый компромисс для языка шаблонов, он неприемлем для языка программирования общего назначения, такого как Python.

Answer 4

В дополнение к уже опубликованным пунктам, учтите это.Python использует специальные переменные-члены и функции для предоставления метаданных об объекте.И переводчик, и программисты активно их используют.Например, dict s и list s имеют функцию-член __len__.Теперь, если доступ к данным dict осуществляется с помощью оператора ., потенциальная неоднозначность возникает, если у dict есть ключ с именем __len__.Вы могли бы особый случай этих, но многие объекты имеют атрибут __dict__, который представляет собой отображение имен и значений членов.Если бы этот объект оказался контейнером, который также определил атрибут __len__, вы бы оказались в полном беспорядке.

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

Теперь учтите, что новые пользователи часто затеняют встроенные модули (если в вопросах SO есть какой-либо признак), и что-то в этом роде начинает казаться очень плохой идеей, поскольку это усугубит проблемуфолд.

Answer 5

• Различные методы доступа к атрибутам делают разные вещи.Если у вас есть функция foo, две строки кода a = foo, a = foo() делают две совершенно разные вещи.Без четкого синтаксиса для ссылок и вызова функций у питона не было бы возможности узнать, должна ли переменная быть ссылкой на foo или результатом выполнения foo.Синтаксис () устраняет неоднозначность.
• Списки и словари - это две очень разные структуры данных.Одна из вещей, которая определяет, какая из них подходит в данной ситуации, - это то, как можно получить доступ к ее содержимому (ключ против индекса).Наличие отдельного синтаксиса для них обоих усиливает представление о том, что эти две вещи не одинаковы, и ни одна из них не всегда уместна.язык шаблонов, человеку, пишущему html, все равно, язык шаблонов не имеет указателей функций, поэтому он знает, что он вам не нужен.Программисты, которые пишут Python, который управляет шаблоном, однако, заботятся об этих различиях.