Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
def is_tuple(node: Node) -> bool:
match node:
case Node(children=[LParen(), RParen()]):
return True
case Node(children=[Leaf(value="("), Node(), Leaf(value=")")]):
return True
case _:
return Falsehttps://www.python.org/dev/peps/pep-0622/
Запостил: 
MAKAKA,
23 Июня 2020
Follow us!
утиная тупизация
омерзительно
> struct User
Несоответствие условиям задачи.
Скобочки вместо точки юзать придётся.
Говно, кстати.
Говно, говно, говно.
Зачем это ненужное различие?
Мне нравится, как сделано в JS и Lua.
Где сказано, что тайпдикт не рекомендуется использовать в качестве структуры данных?
Потому что в «Питоне» «TypedDict» — это просто «dict». В «Питоне» нет никаких различий между «dict» и «TypedDict».
> Где сказано, что тайпдикт не рекомендуется использовать в качестве структуры данных?
В качестве структуры данных можно использовать что угодно, включая массив и словарь. А вот описание структуры данных — совсем другой вопрос.
Один хер это откуда-нибудь из базы.
Если это экспортируемая функция (либо если в мудуле она используется во многих местах) и какого-либо расширения её функционала не планируется (например, добавления e-mail'а или какой-то логики), то namedtuple('...', ['user_name', 'user_id']) или @dataclass.
Если в дальнейшем может потребоваться расширить возвращаемое значение (добавить поля, добавить какие-то методы) — то @dataclass.
Ну а если делать не как лениво, а как правильно, то только @dataclass.
А если совсем правильно, то, как подсказывает, Борманд, объект класса «User» из ORM.
И, конечно, в изначальной задаче речь шла про другое. Дело в том, что «структура данных» и просто «структура» — это два совершенно разных понятия. «Структура данных» — она же «абстрактный тип данных» — это описание интерфейса и поведения некоторого способа хранения данных: «список», «двоичное дерево», «куча», etc. А указанная в задаче «структура» — это, собственно, описание типа данных, их интерфейса.
«TypedDict» не подходит для задачи просто потому, что он не описывает требуемый интерфейс в самом языке. На уровне языка (а не внешних утилит вроде «mypy») экземпляр подкласса «TypedDict» полностью эквивалентен (ну, конечно, если не переопределять __init__() и другие методы, но в этом смысла нет) экземпляру класса «dict», то есть словарю.
> (кстати, по твоему получается, что описать ADT там нельзя?).
Я про «ADT» ничего не говорил.
расшифруй пжлста ADT
>>> Формально АТД может быть определён как множество объектов, определяемое списком компонентов (операций, применимых к этим объектам, и их свойств). Вся внутренняя структура такого типа спрятана от разработчика программного обеспечения — в этом и заключается суть абстракции. Абстрактный тип данных определяет набор функций, независимых от конкретной реализации типа, для оперирования его значениями. Конкретные реализации АТД называются структурами данных.
Список — ADT, дерево — ADT, словарь — ADT, User — не ADT, Movie — не ADT.
Спасибо.
Подставим теперь расшифровку в твою фразу:
>Не «Абстрактный тип данных», а тип данных
Тебя ничего не смущает?
Нет. «Абстрактный тип данных» и «тип данных» — это два разных понятия с разными значениями. Повторюсь: эти названия придумывал не я.
"In computer science, an abstract data type (ADT) is a mathematical model for data types"
То-есть ADT это математическая модель типов, как же она может быть "разным понятием"?
Но мы отвлеклись: если информацию можно получить в рантайме, то мы говорим, что сущность описана в питоне
Если нельзя, то не описана
верно?
Формула «x^2 + y^2 + z^2 = r^2» — это математическая модель футбольного мяча. Следует ли из этого, что формула «x^2 + y^2 + z^2 = r^2» и футбольный мяч — это два одинаковых понятия?
> верно?
Нет, неверно. Обратимся ко википедийному определению понятия «Data type»:
Сообщает ли Movie(TypedDict) компилятору или интерпретатору способ, которым программист собирается использовать соответствующие данные? Нет, не сообщает: он в точности равен способу использования обычного dict.
Ограничивает ли Movie(TypedDict) множество значений, которое может принимать соответствующая переменная? Нет, не ограничивает: оно в точности равно множеству значений dict.
Определяет ли Movie(TypedDict) набор операций, которые могут быть выполнены над соответствующими данными? Нет, не определяет: этот набор в точности равен таковому для dict.
Является ли Movie(TypedDict) отдельным типом? Нет, не является.
Продолжим тем, что ADT — это математическая модель, и к дискуссии это понятие не имеет никакого отношения. Ты что, ма-те-ма-тик из раш-ки?
Закончим на том, что если в языке появится директива, которая изменяет семантику языка, то измениться может что угодно, и даже TypedDict стать типом данных (data type).
И для уточнения давай уточним: что такое структура из исходной задачи?
>>>
В рантайме же типизация вполне есть
Подтверждаю. У питоньей статотипизации две беды основных проблемы.
Во-первых, из-за очень высокой степени динамичности организовать статическую типизацию может быть сложно (всяческие декораторы и создание классов в рантайме а-ля «namedtuple» делают статическую проверку типов очень весёлым и увлекательным занятием).
Во-вторых, из-за слишком позднего введения (3.5, кажется) в экосистеме «Питона» оказалось огромное количество либ, которые к статотипизации в принципе не готовы, а переписывать их — огромный геморрой. Реальные примеры: «numpy», «Flask», «Tensorflow» — в общем, практически любая крупная либа, написанная раньше 2014-го года. Конечно, отдельные энтузиасты пилят всяческие «type stubs», но это весьма посредственное, кривое и неполноценное решение.
В итоге получается, что сейчас статическая типизация «Питона» — это скорее «игрушечная» штука, PoC. Писать с ней что-то крупное практически бессмысленно, и вряд ли в будущем что-то изменится — ещё одного 2->3 «Питон» точно не переживёт, а без этого PEP484 так и останется просто забавным курьёзом.
Имхо, вполне нормально (напоминает .h файлы, лол), но только их надо делать. А их не делают. Потому что всем похуй.
>из-за очень высокой степени динамичности
..которая в 90% случаев не нужна.
Какие-то штуки (к примеру Django ORM) статически не типизировать, во всяком случае не такой типизацией, как в 484.
Но большую часть вполне можно было бы покрыть.
Но всем похуй.
В итоге PyCharm у меня часть типов берет из хинтов, часть сам выводит, часть вообще не понимает.. Метод безопасно не переименовать даже.
Просто их делают хуй пойми кто, и хуй пойми кто поддерживает.
Помню, несколько месяцев назад пытался прикрутить типизацию к «NumPy» — наткнулся на что-то вроде https://github.com/numpy/numpy-stubs, посмотрел на «2 years ago», кучу незакрытых ишшуев, описание наполеоновских планов в ридми, да и плюнул. Ну а 20 дней назад они перенеслись в основную репу «NumPy» — не прошло и трёх лет.
> Какие-то штуки (к примеру Django ORM) статически не типизировать, во всяком случае не такой типизацией, как в 484.
Ну да, я ж и говорю, что всяческие ORM'ы сосут. ЕМНИП, «mypy» до сих пор даже декораторы и «namedtuple» нормально вывести не может.