Комментарии 19
Языку шёл двадцать восьмой год… Теперь ждём ещё три-пять лет до очередного озарения Гвидо?
0
Что то мне говорит, что Светлов приложил сюда руку…
+2
Вот бы еще ВМ опиралась на хинтинг типов при предсказании типа. Сколько пишу на питоне, мне это всегда казалось самым слабым местом языка. Одни мытарства numpy и numba чего стоят.
0
Выглядит как набор костылей. Есть же нормальный Named Tuple, который и класс, и кортеж, и проверяет равенство по данным, а не ссылкам. И ради трех полей вводить столько абстракций… зачем?
-1
Вы не пробовали сначала прочитать статью, а уже потом комментировать?
+2
Да, я прочитал всю статью, в т.ч. где упоминается Named Tuple. Непонятки в силе.
0
Как минимум два пункта очень сильно мешают:
- обязательная неизменяемость,
- равенство переменных двух разных логических типов.
Изменить это поведение нельзя, так как это сделает namedtuple несовместимым с обычным tuple
+1
Ради трёх полей может и не стоит, конечно, но если посмотреть какой лютый треш творится в исходниках разных ORM и ODM типа MongoEngine или SQLAlchemy для вот этого всего… Тут хоть попытка стандартизовать механизм.
И всё равно, наверняка, остаётся много тонких неудобных мест с кастомными типами полей.
Конечно не везде уместно использовать такие структуры, но в некоторых случаях это спасёт от лютого велосипедостроения на словарях и метаклассах.
И всё равно, наверняка, остаётся много тонких неудобных мест с кастомными типами полей.
Конечно не везде уместно использовать такие структуры, но в некоторых случаях это спасёт от лютого велосипедостроения на словарях и метаклассах.
0
Получается, что ОРМ и прочие библиотеки все равно не смогут этим воспользоваться, потому что это введет ограничение на версию Питона >= 3.7. Лучше было вынести в библиотеку.
0
Помнится, я изобретал костыль как-то для избежания лишней писанины при создании классов.
Понятно, что это жуткий хак, и такое не стоит тащить в продакшн, зато выручало в тех случаях, когда трудно сходу определиться со списком аргументов в __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__).
0
Написать-то можно. Главная проблема — инспектор кода в том же PyCharm'е будет постоянно жаловаться, что в переменная не инициализирована в __init__.
0
Ну я в общем-то и не утверждал, что это полностью ready-to-use решение.
С PyCharm иметь дел не приходилось.
Другим возможным решением могла бы стать динамическая генерация кода __init__, но на мой взгляд, для одноразовых скриптов это был бы оверкилл.
С PyCharm иметь дел не приходилось.
Другим возможным решением могла бы стать динамическая генерация кода __init__, но на мой взгляд, для одноразовых скриптов это был бы оверкилл.
0
А это, кстати, больше проблема PyCharm, имхо. Они никак не впилят своему линтеру понимание, что когда в классе объявлено свойство, то нужно вычислять тип соответствующего атрибута не по типу свойства, а по типу, возвращаемого геттером значения.
0
Я в таких случаях делаю специальный метакласс, который создаёт или обрабатывает свойства на основе атрибутов, задекларированных в теле класса. А в такой конструктор чтобы прокинуть какие-то параметры, которые не нужно хранить, придётся как-то кодировать имена подчеркиваниями, анализировать это… Короче Гвидо будет вертеться в постели от такого пренебрежения ПЕПом.
0
А что мешает создать такой декоратор самому? И-инновации блин
0
почему в примере с инициализирующими переменными gen_desc: InitVar[bool] = True объявляется как bool, а ниже аннотирован как str?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Data classes