Comments 5
Тема интересная. Текущая реализация немного другая: hg.python.org/cpython/file/tip/Lib/collections/__init__.py
В текущей реализации namedtuple всех этих locals() нет, и правильно.
__slots__ не имеет никакого отношения к тому, можно ли использовать объект в качестве ключей в словарях, или нет. Да и неизменяемость, в общем-то, не обязательна. См. docs.python.org/3/glossary.html#term-hashable.
Использование locals() для строковой интерполяции мне кажется очень удобным. Питону не хватает простой интерполяции локальных переменных. В Groovy и CoffeeScript, например, можно написать что-то вроде "{name} is {some_value}". Но я думаю, что этот Python-вариант вполне сойдёт: "{name} is {some_value}".format(**locals()).
В текущей реализации namedtuple всех этих locals() нет, и правильно.
Вы, наверное, заметили, что __slots__ определяется как пустой кортеж. Питон в таком случае не использует для экземпляров словари в качестве пространств имён, что немного экономит ресурсы. Благодаря неизменяемости, которая наследуется от родительского класса (tuple), и невозможности добавлять новые атрибуты (потому что __slots__ = ()), экземпляры namedtuple-типов являются объектами-значениями, что позволяет использовать их, например, в качестве ключей в словарях.
__slots__ не имеет никакого отношения к тому, можно ли использовать объект в качестве ключей в словарях, или нет. Да и неизменяемость, в общем-то, не обязательна. См. docs.python.org/3/glossary.html#term-hashable.
__slots__ не имеет никакого отношенияСпасибо за верное замечание. В статье такого нет, это мой косяк :)
locals() нет, и правильноСогласен, explicit is better.
Действительно, реализация стала чище с использованием format.
P.S. Ну надо же как все просто реализовано в Питоне, я был почте уверен, что внутри побольше магии.
P.S. Ну надо же как все просто реализовано в Питоне, я был почте уверен, что внутри побольше магии.
В этой статье-переводе
Добавьте ссылку на оригинал
Sign up to leave a comment.
Как устроен namedtuple или динамическое создание типов