- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
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 False
MAKAKA 23.06.2020 22:58 # 0
утиная тупизация
KOPOHABuPYC 24.06.2020 00:46 # −1
BOKCEJIbHblu_nemyx 27.06.2020 19:23 # 0
MAKAKA 23.06.2020 22:58 # 0
Fike 27.06.2020 14:03 # 0
Fike 27.06.2020 19:11 # +1
омерзительно
guest8 23.06.2020 23:13 # −999
gost 27.06.2020 19:16 # +1
BOKCEJIbHblu_nemyx 27.06.2020 19:28 # 0
guest8 27.06.2020 20:41 # −999
nemyx 28.06.2020 07:09 # +1
guest8 27.06.2020 20:43 # −999
gost 28.06.2020 03:53 # +1
> struct User
guest8 28.06.2020 12:48 # −999
gost 28.06.2020 12:59 # 0
guest8 28.06.2020 13:25 # −999
gost 28.06.2020 13:38 # 0
Несоответствие условиям задачи.
guest8 28.06.2020 13:39 # −999
guest8 28.06.2020 13:48 # −999
bormand 28.06.2020 20:03 # 0
Скобочки вместо точки юзать придётся.
MAKAKA 29.06.2020 18:25 # 0
Говно, кстати.
Говно, говно, говно.
Зачем это ненужное различие?
Мне нравится, как сделано в JS и Lua.
gost 28.06.2020 20:55 # 0
MAKAKA 28.06.2020 21:08 # 0
Где сказано, что тайпдикт не рекомендуется использовать в качестве структуры данных?
gost 28.06.2020 21:18 # 0
Потому что в «Питоне» «TypedDict» — это просто «dict». В «Питоне» нет никаких различий между «dict» и «TypedDict».
> Где сказано, что тайпдикт не рекомендуется использовать в качестве структуры данных?
В качестве структуры данных можно использовать что угодно, включая массив и словарь. А вот описание структуры данных — совсем другой вопрос.
guest8 28.06.2020 21:20 # −999
gost 28.06.2020 21:26 # 0
guest8 29.06.2020 01:38 # −999
bormand 29.06.2020 01:40 # 0
Один хер это откуда-нибудь из базы.
gost 29.06.2020 01:59 # +2
Если это экспортируемая функция (либо если в мудуле она используется во многих местах) и какого-либо расширения её функционала не планируется (например, добавления e-mail'а или какой-то логики), то namedtuple('...', ['user_name', 'user_id']) или @dataclass.
Если в дальнейшем может потребоваться расширить возвращаемое значение (добавить поля, добавить какие-то методы) — то @dataclass.
Ну а если делать не как лениво, а как правильно, то только @dataclass.
А если совсем правильно, то, как подсказывает, Борманд, объект класса «User» из ORM.
И, конечно, в изначальной задаче речь шла про другое. Дело в том, что «структура данных» и просто «структура» — это два совершенно разных понятия. «Структура данных» — она же «абстрактный тип данных» — это описание интерфейса и поведения некоторого способа хранения данных: «список», «двоичное дерево», «куча», etc. А указанная в задаче «структура» — это, собственно, описание типа данных, их интерфейса.
«TypedDict» не подходит для задачи просто потому, что он не описывает требуемый интерфейс в самом языке. На уровне языка (а не внешних утилит вроде «mypy») экземпляр подкласса «TypedDict» полностью эквивалентен (ну, конечно, если не переопределять __init__() и другие методы, но в этом смысла нет) экземпляру класса «dict», то есть словарю.
guest8 29.06.2020 15:29 # −999
gost 29.06.2020 16:09 # 0
> (кстати, по твоему получается, что описать ADT там нельзя?).
Я про «ADT» ничего не говорил.
MAKAKA 29.06.2020 16:13 # 0
расшифруй пжлста ADT
gost 29.06.2020 16:33 # 0
>>> Формально АТД может быть определён как множество объектов, определяемое списком компонентов (операций, применимых к этим объектам, и их свойств). Вся внутренняя структура такого типа спрятана от разработчика программного обеспечения — в этом и заключается суть абстракции. Абстрактный тип данных определяет набор функций, независимых от конкретной реализации типа, для оперирования его значениями. Конкретные реализации АТД называются структурами данных.
Список — ADT, дерево — ADT, словарь — ADT, User — не ADT, Movie — не ADT.
MAKAKA 29.06.2020 16:42 # 0
Спасибо.
Подставим теперь расшифровку в твою фразу:
>Не «Абстрактный тип данных», а тип данных
Тебя ничего не смущает?
gost 29.06.2020 16:47 # 0
Нет. «Абстрактный тип данных» и «тип данных» — это два разных понятия с разными значениями. Повторюсь: эти названия придумывал не я.
MAKAKA 29.06.2020 16:55 # 0
"In computer science, an abstract data type (ADT) is a mathematical model for data types"
То-есть ADT это математическая модель типов, как же она может быть "разным понятием"?
Но мы отвлеклись: если информацию можно получить в рантайме, то мы говорим, что сущность описана в питоне
Если нельзя, то не описана
верно?
gost 29.06.2020 17:23 # 0
Формула «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) отдельным типом? Нет, не является.
gost 29.06.2020 17:23 # 0
guest8 29.06.2020 18:16 # −999
gost 29.06.2020 18:45 # 0
Продолжим тем, что ADT — это математическая модель, и к дискуссии это понятие не имеет никакого отношения. Ты что, ма-те-ма-тик из раш-ки?
Закончим на том, что если в языке появится директива, которая изменяет семантику языка, то измениться может что угодно, и даже TypedDict стать типом данных (data type).
И для уточнения давай уточним: что такое структура из исходной задачи?
>>>
guest8 29.06.2020 18:55 # −999
bormand 28.06.2020 21:23 # 0
guest8 28.06.2020 21:26 # −999
nemyx 28.06.2020 21:56 # 0
gost 28.06.2020 21:26 # 0
MAKAKA 29.06.2020 16:58 # 0
В рантайме же типизация вполне есть
gost 29.06.2020 17:25 # 0
guest8 29.06.2020 19:07 # −999
nemyx 29.06.2020 19:32 # 0
gost 29.06.2020 19:47 # 0
Подтверждаю. У питоньей статотипизации две беды основных проблемы.
Во-первых, из-за очень высокой степени динамичности организовать статическую типизацию может быть сложно (всяческие декораторы и создание классов в рантайме а-ля «namedtuple» делают статическую проверку типов очень весёлым и увлекательным занятием).
Во-вторых, из-за слишком позднего введения (3.5, кажется) в экосистеме «Питона» оказалось огромное количество либ, которые к статотипизации в принципе не готовы, а переписывать их — огромный геморрой. Реальные примеры: «numpy», «Flask», «Tensorflow» — в общем, практически любая крупная либа, написанная раньше 2014-го года. Конечно, отдельные энтузиасты пилят всяческие «type stubs», но это весьма посредственное, кривое и неполноценное решение.
В итоге получается, что сейчас статическая типизация «Питона» — это скорее «игрушечная» штука, PoC. Писать с ней что-то крупное практически бессмысленно, и вряд ли в будущем что-то изменится — ещё одного 2->3 «Питон» точно не переживёт, а без этого PEP484 так и останется просто забавным курьёзом.
MAKAKA 29.06.2020 19:55 # 0
Имхо, вполне нормально (напоминает .h файлы, лол), но только их надо делать. А их не делают. Потому что всем похуй.
>из-за очень высокой степени динамичности
..которая в 90% случаев не нужна.
Какие-то штуки (к примеру Django ORM) статически не типизировать, во всяком случае не такой типизацией, как в 484.
Но большую часть вполне можно было бы покрыть.
Но всем похуй.
В итоге PyCharm у меня часть типов берет из хинтов, часть сам выводит, часть вообще не понимает.. Метод безопасно не переименовать даже.
gost 29.06.2020 20:05 # 0
Просто их делают хуй пойми кто, и хуй пойми кто поддерживает.
Помню, несколько месяцев назад пытался прикрутить типизацию к «NumPy» — наткнулся на что-то вроде https://github.com/numpy/numpy-stubs, посмотрел на «2 years ago», кучу незакрытых ишшуев, описание наполеоновских планов в ридми, да и плюнул. Ну а 20 дней назад они перенеслись в основную репу «NumPy» — не прошло и трёх лет.
> Какие-то штуки (к примеру Django ORM) статически не типизировать, во всяком случае не такой типизацией, как в 484.
Ну да, я ж и говорю, что всяческие ORM'ы сосут. ЕМНИП, «mypy» до сих пор даже декораторы и «namedtuple» нормально вывести не может.
guest8 28.06.2020 18:41 # −999