Мне выискивать и цитировать все, немного лень. Ну например вас огорчает отсутствие public и private, и вот вы уже хотите использовать всю мощь языка и перекрыть доступ к атрибутам при помощи тяжелой магии. В python так не делают.
Потом у вас странная цель сразу написать свой фреймворк, зачем? Изучите вначале хотя бы один, чтобы вообще почувствовать, как это работает в python.
В общем один из возможных стартов, прочесть и выполнить упражнения к django, те, что на официальном сайте.
Визуально ужасен, если много. Сравниваем — Product.id vs Product['id'].
Get и setdefault отличные методы, и их тоже надо использовать, я с вами абсолютно согласен. И ни в коем случае извращаться с getattr над словарем я не собираюсь. С другой стороны, если кто-то использующий библиотеку, сунет этот класс куда-то, где дернется getattr, то все сработает как ожидалось.
Но предположим, что некто, крайне пуританских взглядов, решил не мимикрировать словарь под объект, а создать честный объект. Как он будет проходиться по атрибутам своего объекта? Через задний проход, потому что объекты не предназначены для обхода атрибутов. А с нашим словариком он просто сделает for k, v in product.items(). Это если не вспоминать о времени, затрачиваемом на сборку объекта на лету, и его разборку перед упаковкой в БД.
Итак есть два пути — заточить объект так, чтобы он мимикрировал свое поведение под словарь, или не выпендриваться, и обернуть словарь так как надо, а методы словаря, оптимизированные, написанные на C, достанутся на халяву.
Напоминаю про namedtuple, которым все пользуются, но который является точно такой же надстройкой над tuple. Ну и кто от его использования пострадал? Ну только настоящие питонисты, которых бесит передача списка полей строкой, получили психологическую травму, увидев такое в stdlib.
Вы похоже не читаете, что комментируете. Беседовать с человеком, который читает в моем тексте то, что он желает, не стоит моего времени. Наша встреча была ошибкой.
In [6]: P.__mro__
Out[6]: (<class '__main__.P'>, <type 'tuple'>, <type 'object'>)
Сволочи, они снаследовались от кортежа! На костер.
Я кстати за костер, но по другим причинам — namedtuple это образец кривости, это непередаваемый пи. Ну что стоило принять хотя бы кортеж, а не строку?? И вот вы этим говном пользуется, а значит __getattr__ переопределить это немыслимо?
В своей библиотеке я буду работать со словарем так, как мне это кажется правильным. А чтобы не путаться надо хотя бы readme читать.
Я понимаю, вам кажется, что вы тут боретесь за чистоту языка, но это не так. Никто язык не трогает. Словарь это такой же класс, как и все остальные, от него также можно унаследоваться, и переделать его поведение под себя. Если вам это кажется наглостью, то уберите из stdlib defaultdict. Он тоже трогает святое.
Дурной тон, это путать понятия. Синтаксис языка определяет доступ к элементам объекта через точку. Мы не затрагиваем синтаксис, мы используем стандартную, и очень активно используемую, возможность языка, чтобы в рамках его синтаксиса добавить сахара к работе со словарем. И никто не сказал, что это будет простой вызов __getitem__, может там какие-то дополнительные обработки обнаружатся, проверка данных, например.
То есть реализуется некий класс, поведение которого отличается от обычного словаря, но порядок работы как со словарем нет. То есть где нужен словарь, он остается словарем. И это очень удобно, это экономит время на сборке/разборке объекта.
— namedtuple достаточно статичная вещь, а документы в MongoDB (в качестве примера) вещь изменчивая. и четкой структуры не имеющая.
Еще я вам кратко ответил, надо разъяснить — понятный код в Python это принцип! Это заповедь программиста.
Но ведь писать понятный код надо начиная с момента, когда количество участников разработки переваливает за ноль, и стремительно приближается к единице.
Так вот лишние элементы, не несущие смысловой нагрузки, никак не улучшают восприятие. Когда я смотрю на разряженный код C/C++/Java, я отчетливо ощущаю раздражение от совершенно ненужных {};, за которыми еще и следить приходится.
Ну ну, на десятом вопросе «а вот в php я делал так», у вас коллективно проснется желание забанить нового участника сообщества навсегда, хорошо если без физических воздействий.
Да не пытаетесь вы. Вы берете свои привычки из PHP и тянете их в Python, с минимальной адаптацией, без разбора, что языки разные, очень разные. С точно таким же успехом вы будете писать на LISP как на PHP. Так с чего бы ощутить разницу? Вы пишете все также на PHP, просто вминаете свой PHP в чужеродные конструкции. Так только батхерт можно ощутить, а не преимущества.
Вам надо переключиться, и врубиться — это не PHP, не JAVA и не С. Это Python/Ruby/PREL/LISP/Erlang/Ocaml/_нужное вписать_. Выкиньте свои привычки, и научитесь новому языку.
Это не означает, что при написании программ на императивном python вам нельзя использовать немного функционального стиля. Тот же sum() восхитителен. Но если вы начнете писать на LISP в python, вы получите говнокод.
Ну можете колдовать со сборкой объектов, и дальнейшей их обратной разборкой. В MongoDB словарики, не забыли? Так зачем делать двойную работу? Потому что сто пятьдесят криворучек не смогли корректно написать __getattr__?
Ну и тут вроде python обсуждается, а не c++, большая концентрация [] на строку вредна для психики.
Реализацию мимикрии словаря под объект предлагаю не обсуждать, она конечно хромая.
Но сама возможность такой работы со словарем, бывает удобной.
Например я вижу работу с современными NoSQL БД именно через словари, а не через прибитые гвоздями модели. Но доступ к элементам словаря стандартными языковыми средствами просто ужасен. Если у вас в коде таких обращений будет много, на него будет страшно смотреть.
Платформа, видимо, появилась как слово, была вначале ;-) Я имею ввиду, что в платформе тоже бывают баги. Но тестировать то конечно стоит, баги надо обходить.
Ну если бы я знал, я бы прям так бы и резанул правду матку: ) Но я просто спросил, спасибо за ответ. Электротехника у меня основательно выветрилась, за невостребованностью.
Потом у вас странная цель сразу написать свой фреймворк, зачем? Изучите вначале хотя бы один, чтобы вообще почувствовать, как это работает в python.
В общем один из возможных стартов, прочесть и выполнить упражнения к django, те, что на официальном сайте.
Get и setdefault отличные методы, и их тоже надо использовать, я с вами абсолютно согласен. И ни в коем случае извращаться с getattr над словарем я не собираюсь. С другой стороны, если кто-то использующий библиотеку, сунет этот класс куда-то, где дернется getattr, то все сработает как ожидалось.
Но предположим, что некто, крайне пуританских взглядов, решил не мимикрировать словарь под объект, а создать честный объект. Как он будет проходиться по атрибутам своего объекта? Через задний проход, потому что объекты не предназначены для обхода атрибутов. А с нашим словариком он просто сделает for k, v in product.items(). Это если не вспоминать о времени, затрачиваемом на сборку объекта на лету, и его разборку перед упаковкой в БД.
Итак есть два пути — заточить объект так, чтобы он мимикрировал свое поведение под словарь, или не выпендриваться, и обернуть словарь так как надо, а методы словаря, оптимизированные, написанные на C, достанутся на халяву.
Напоминаю про namedtuple, которым все пользуются, но который является точно такой же надстройкой над tuple. Ну и кто от его использования пострадал? Ну только настоящие питонисты, которых бесит передача списка полей строкой, получили психологическую травму, увидев такое в stdlib.
In [6]: P.__mro__
Out[6]: (<class '__main__.P'>, <type 'tuple'>, <type 'object'>)
Сволочи, они снаследовались от кортежа! На костер.
Я кстати за костер, но по другим причинам — namedtuple это образец кривости, это непередаваемый пи. Ну что стоило принять хотя бы кортеж, а не строку?? И вот вы этим говном пользуется, а значит __getattr__ переопределить это немыслимо?
Я понимаю, вам кажется, что вы тут боретесь за чистоту языка, но это не так. Никто язык не трогает. Словарь это такой же класс, как и все остальные, от него также можно унаследоваться, и переделать его поведение под себя. Если вам это кажется наглостью, то уберите из stdlib defaultdict. Он тоже трогает святое.
То есть реализуется некий класс, поведение которого отличается от обычного словаря, но порядок работы как со словарем нет. То есть где нужен словарь, он остается словарем. И это очень удобно, это экономит время на сборке/разборке объекта.
— namedtuple достаточно статичная вещь, а документы в MongoDB (в качестве примера) вещь изменчивая. и четкой структуры не имеющая.
Но ведь писать понятный код надо начиная с момента, когда количество участников разработки переваливает за ноль, и стремительно приближается к единице.
Так вот лишние элементы, не несущие смысловой нагрузки, никак не улучшают восприятие. Когда я смотрю на разряженный код C/C++/Java, я отчетливо ощущаю раздражение от совершенно ненужных {};, за которыми еще и следить приходится.
Вам надо переключиться, и врубиться — это не PHP, не JAVA и не С. Это Python/Ruby/PREL/LISP/Erlang/Ocaml/_нужное вписать_. Выкиньте свои привычки, и научитесь новому языку.
Это не означает, что при написании программ на императивном python вам нельзя использовать немного функционального стиля. Тот же sum() восхитителен. Но если вы начнете писать на LISP в python, вы получите говнокод.
Ну и тут вроде python обсуждается, а не c++, большая концентрация [] на строку вредна для психики.
Но сама возможность такой работы со словарем, бывает удобной.
Например я вижу работу с современными NoSQL БД именно через словари, а не через прибитые гвоздями модели. Но доступ к элементам словаря стандартными языковыми средствами просто ужасен. Если у вас в коде таких обращений будет много, на него будет страшно смотреть.