Исправление byko3y, (текущая версия) :
Но это все эти потуги в питоне представляют собой полумеры. Питону нужна распределенная диспетчеризация, примерно как trait в расте (не важно, во время компиляции, исполнения, интерпретации, или чего бы то ни было еще). То есть, если я складываю объект А с объектом Б, то вызывается не метод объекта, и не встроенный в интерпретатор костыль, а функция, которая объявлена как функция сложения с аргументами типа А и Б. Проблемы возникают разве что с самим определением «тип». Поскольку в питоне очень распространена утиная типизация, а наследованию мы объявили войну, то класс объекта не может служить его типом в данном случае. Скорее, нужно что-то вроде интерфейса, протокола, растовых типажей (trait). Например, объект имеет __iter__ - он становится автоматически обладателем типажа «итератор». Правда, если так широко загребать объекты под типажи, то очень быстро возникает ситуация, когда конфликтующие типажи представляются абсолютно одинаковыми атрибутами. С другой стороны, не хотелось бы скатиться в крестовые обобщения с многоуровневыми объявлениями типов, как то в ренжах, где объявления шаблонов раз в пять больше, чем сам код реализации алгоритма. Потому есть смысл вдобавок к автоматическому присвоению типажей сделать явное объявление типажей, вроде «вот эти мои атрибуты принадлежат такому-то типажу, а никакому не другому».
Пока что в общих чертах идея мне нравится тем, что она должна будет минимально изменить конечный код (или даже вообще оставить как есть), потому что основной хассл отправляется в стандартную библиотеку и в сам транслятор, где транслятор по правилам из библиотеки будет сидеть и лепить вызовы функций с типажами, аки конструктор лего. Он и так сейчас их лепит, просто делает это беспорядочно.
Исходная версия byko3y, :
Но это все эти потуги в питоне представляют собйо полумеры. Питону нужна распределенная диспетчеризация, примерно как trait в расте (не важно, во время компиляции, исполнения, интерпретации, или чего бы то ни было еще). То есть, если я складываю объект А с объектом Б, то вызывается не метод объекта, и не встроенный в интерпретатор костыль, а функция, которая объявлена как функция сложения с аргументами типа А и Б. Проблемы возникают разве что с самим определением «тип». Поскольку в питоне очень распространена утиная типизация, а наследованию мы объявили войну, то класс объекта не может служить его типом в данном случае. Скорее, нужно что-то вроде интерфейса, протокола, растовых типажей (trait). Например, объект имеет __iter__ - он становится автоматически обладателем типажа «итератор». Правда, если так широко загребать объекты под типажи, то очень быстро возникает ситуация, когда конфликтующие типажи представляются абсолютно одинаковыми атрибутами. С другой стороны, не хотелось бы скатиться в крестовые обобщения с многоуровневыми объявлениями типов, как то в ренжах, где объявления шаблонов раз в пять больше, чем сам код реализации алгоритма. Потому есть смысл вдобавок к автоматическому присвоению типажей сделать явное объявление типажей, вроде «вот эти мои атрибуты принадлежат такому-то типажу, а никакому не другому».
Пока что в общих чертах идея мне нравится тем, что она должна будет минимально изменить конечный код (или даже вообще оставить как есть), потому что основной хассл отправляется в стандартную библиотеку и в сам транслятор, где транслятор по правилам из библиотеки будет сидеть и лепить вызовы функций с типажами, аки конструктор лего. Он и так сейчас их лепит, просто делает это беспорядочно.