Наличие двух различных семантик для одного имени метода — веская причина метод с таким названием не делать частью стандартной библиотеки.
Для строго типизированных языков придётся определить рекурсивный тип Tree[T] как T | List[Tree[T]] и сказать, что функция top имеет тип Tree[T] → List[T]. (А альтернативная семантика — это просто concat или монадный join.)
Если flatten многозначен, то flatten_once и flatten_recursively снял бы все вопросы. Или даже .flatten(recursive=True).
Тут ещё одна проблема, что в питоне полный раздрай между методами (str.strip()), магическими методами для функций из прелюдии (len(str)) и "инверсными" методами вроде ",".join(str).
Чем больше я таких странностей в питоне вижу, тем мне грустнее с ним работать.
Не, к дизайну API стандартной библиотеки у меня больших вопросов нет. Магические методы для поддержки перегрузки операторов всё равно нужны. Ну, может быть, они бы смотрелись красивее, если бы назывались не dunder-именами, а operator **, как в C++, но вот как раз метод, имя которого не является валидным идентификатором, магичнее dunder’а. Джойн нескольких строк в строку через разделитель-строку выглядит чужеродно как метод класса списка — потому что лишь малая часть всех списков является списком строк. И ещё джойнить же хочется не только списки, но любые итерабли.
Вот то, что issubclass(bool, int) и !issubclass(int, float) — это печалька.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amarao
no subject
Date: 2023-03-01 05:57 pm (UTC)no subject
Date: 2023-03-01 07:09 pm (UTC)Материализация всех промежуточных списков.
no subject
Date: 2023-03-02 12:06 pm (UTC)Вот, кстати, я сейчас подумал про семантику flatten для питона... В силу мягкой типизации, я ожидаю, что вот это тоже будет flatten:
[1, [1,2], [3, [4, [5]]]], в [1,2,3,4,5]
Я не уверен в soundness такого для Rust'а, но |flatten в jinja делает именно это. "Я хочу линейный список".
no subject
Date: 2023-03-02 01:14 pm (UTC)Наличие двух различных семантик для одного имени метода — веская причина метод с таким названием не делать частью стандартной библиотеки.
Для строго типизированных языков придётся определить рекурсивный тип
Tree[T]какT | List[Tree[T]]и сказать, что функцияtopимеет типTree[T] → List[T]. (А альтернативная семантика — это простоconcatили монадныйjoin.)no subject
Date: 2023-03-02 02:18 pm (UTC)Если flatten многозначен, то flatten_once и flatten_recursively снял бы все вопросы. Или даже .flatten(recursive=True).
Тут ещё одна проблема, что в питоне полный раздрай между методами (str.strip()), магическими методами для функций из прелюдии (len(str)) и "инверсными" методами вроде ",".join(str).
Чем больше я таких странностей в питоне вижу, тем мне грустнее с ним работать.
no subject
Date: 2023-03-02 03:45 pm (UTC)Не, к дизайну API стандартной библиотеки у меня больших вопросов нет. Магические методы для поддержки перегрузки операторов всё равно нужны. Ну, может быть, они бы смотрелись красивее, если бы назывались не dunder-именами, а
operator **, как в C++, но вот как раз метод, имя которого не является валидным идентификатором, магичнее dunder’а. Джойн нескольких строк в строку через разделитель-строку выглядит чужеродно как метод класса списка — потому что лишь малая часть всех списков является списком строк. И ещё джойнить же хочется не только списки, но любые итерабли.Вот то, что
issubclass(bool, int)и!issubclass(int, float)— это печалька.no subject
Date: 2023-03-03 11:43 am (UTC)У меня не вызывают вопросы len, eq и т.д.
У меня вызывают вопрос len (почему len(str), а не str.len()), собственно, repr/str() (должны быть .repr() и .str()), а так же ' '.join([str]).
Насчёт float'а, считать его подмножеством int'а - ошибка.
1e63+1 == 1e63