Комментарии 19
Языку шёл двадцать восьмой год… Теперь ждём ещё три-пять лет до очередного озарения Гвидо?
Что то мне говорит, что Светлов приложил сюда руку…
Вот бы еще ВМ опиралась на хинтинг типов при предсказании типа. Сколько пишу на питоне, мне это всегда казалось самым слабым местом языка. Одни мытарства numpy и numba чего стоят.
Выглядит как набор костылей. Есть же нормальный Named Tuple, который и класс, и кортеж, и проверяет равенство по данным, а не ссылкам. И ради трех полей вводить столько абстракций… зачем?
Вы не пробовали сначала прочитать статью, а уже потом комментировать?
Да, я прочитал всю статью, в т.ч. где упоминается Named Tuple. Непонятки в силе.
Как минимум два пункта очень сильно мешают:
- обязательная неизменяемость,
- равенство переменных двух разных логических типов.
Изменить это поведение нельзя, так как это сделает namedtuple несовместимым с обычным tuple
Ради трёх полей может и не стоит, конечно, но если посмотреть какой лютый треш творится в исходниках разных ORM и ODM типа MongoEngine или SQLAlchemy для вот этого всего… Тут хоть попытка стандартизовать механизм.
И всё равно, наверняка, остаётся много тонких неудобных мест с кастомными типами полей.
Конечно не везде уместно использовать такие структуры, но в некоторых случаях это спасёт от лютого велосипедостроения на словарях и метаклассах.
И всё равно, наверняка, остаётся много тонких неудобных мест с кастомными типами полей.
Конечно не везде уместно использовать такие структуры, но в некоторых случаях это спасёт от лютого велосипедостроения на словарях и метаклассах.
Помнится, я изобретал костыль как-то для избежания лишней писанины при создании классов.
Понятно, что это жуткий хак, и такое не стоит тащить в продакшн, зато выручало в тех случаях, когда трудно сходу определиться со списком аргументов в __init__ (с учетом того, что на каждое изменение наименования / удаление / добавление аргумента приходятся соответствующие изменения в теле функции __init__).
class MyClass:
def __init__(self, arg1, arg2, arg3):
l = locals()
del l["self"]
for name in l:
setattr(self, name, l[name])
>>> myClass = MyClass(1, 2, 3)
>>> myClass.arg3
3
>>> dir(myClass)
['__doc__', '__init__', '__module__', 'arg1', 'arg2', 'arg3']
Понятно, что это жуткий хак, и такое не стоит тащить в продакшн, зато выручало в тех случаях, когда трудно сходу определиться со списком аргументов в __init__ (с учетом того, что на каждое изменение наименования / удаление / добавление аргумента приходятся соответствующие изменения в теле функции __init__).
Написать-то можно. Главная проблема — инспектор кода в том же PyCharm'е будет постоянно жаловаться, что в переменная не инициализирована в __init__.
Ну я в общем-то и не утверждал, что это полностью ready-to-use решение.
С PyCharm иметь дел не приходилось.
Другим возможным решением могла бы стать динамическая генерация кода __init__, но на мой взгляд, для одноразовых скриптов это был бы оверкилл.
С PyCharm иметь дел не приходилось.
Другим возможным решением могла бы стать динамическая генерация кода __init__, но на мой взгляд, для одноразовых скриптов это был бы оверкилл.
А это, кстати, больше проблема PyCharm, имхо. Они никак не впилят своему линтеру понимание, что когда в классе объявлено свойство, то нужно вычислять тип соответствующего атрибута не по типу свойства, а по типу, возвращаемого геттером значения.
Я в таких случаях делаю специальный метакласс, который создаёт или обрабатывает свойства на основе атрибутов, задекларированных в теле класса. А в такой конструктор чтобы прокинуть какие-то параметры, которые не нужно хранить, придётся как-то кодировать имена подчеркиваниями, анализировать это… Короче Гвидо будет вертеться в постели от такого пренебрежения ПЕПом.
А что мешает создать такой декоратор самому? И-инновации блин
почему в примере с инициализирующими переменными gen_desc: InitVar[bool] = True объявляется как bool, а ниже аннотирован как str?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Data classes