Исправление byko3y, (текущая версия) :
Если у тебя ML — там собственно питона не так много и тот же гугль давно продвигает использовать swift вместо питонов в том же tensorflow для тех, кто хочет нормальные типы...
В питоне взять [0] от потенциально пустого списка — вообще не проблема
Блин, я тут сижу и пытаюсь сообразить, что можно с этим сделать в рамках питона. Легко быть как Кернес: https://www.youtube.com/watch?v=zddj4BA_7OM
Основной механизм, которым хаскель, свифт, лисп, раст, а ныне уже частично и жава с крестами, позволяют не указывать тип, но при этом иметь идеально статические типы - это вывод типов на основе использования переменной. То есть, нужно собрать в кучу всё использование ячейки и придумать ей свойства. Но проблема в том, что ни всевидящий Аллах, ни Господь Саваоф не знают всех вариантов входных данных, которые переварят функции стандартной библиотеки - а ведь это фундамент.
pytype пытается сделать именно вывод типов для проверки корректности кода, что есть похвально, но не поможет в REPL, или ту же стандартную библиотеку вывести не сможет из-за слишком размытых типов онной. Взять тот же итератор, который может быть с __iter__, но может быть с __getitem__ — оба варианта корректны для цикла for.
Неужели ни у кого нет никаких идей? Вот например, статичные описания классов позволяют выводить атрибуты у ячеек и проверять корректность работы с объектами по единому интерфейсу, то есть, по ABC-стилю. Если же на каждый объект во время выполнения еще и вешать критерии корректности работы с этим объектом, то можно в специальном режиме отладки увидеть те ошибки, которые в норме ни статические валидаторы, ни сам CPython выловить не смогут. Например, какой-то отбитый код (не метод объекта) решает добавить свой собственный атрибут в объект - по ошибке или из-за плохого стиля. И тогда валидатор сможет выдать предупреждение, мол, «нарушение инкапсуляции». Или в ячейке лежит строка, но какой-то кусок кода может потенциально положить в ячейку массив - вуаля, получите ошибку в консолю. То есть, по сути это то, что делает JIT-компилятор, только на этот раз JIT-компилятор в явной форме высказывает свои возражения по поводу неоптимизируемости куска кода.
Есть смысл для таких танцев заставлять кодеров объявлять переменные динамического типа явно (val1: Any или val1: Union[list,str]), а жестко ограничиваемый статический тип будет выводиться неявно. Естественно, нужно еще переосмыслить само понятие «тип», чтобы под ним подразумевался абстрактный класс, как с тем же итератором, а не конкретный.
Исходная версия byko3y, :
Если у тебя ML — там собственно питона не так много и тот же гугль давно продвигает использовать swift вместо питонов в том же tensorflow для тех, кто хочет нормальные типы.
В питоне взять [0] от потенциально пустого списка — вообще не проблема
Блин, я тут сижу и пытаюсь сообразить, что можно с этим сделать в рамках питона. Легко быть как Кернес: https://www.youtube.com/watch?v=zddj4BA_7OM
Основной механизм, которым хаскель, свифт, лисп, раст, а ныне уже частично и жава с крестами, позволяют не указывать тип, но при этом иметь идеально статические типы - это вывод типов на основе использования переменной. То есть, нужно собрать в кучу всё использование ячейки и придумать ей свойства. Но проблема в том, что ни всевидящий Аллах, ни Господь Саваоф не знают всех вариантов входных данных, которые переварят функции стандартной библиотеки - а ведь это фундамент.
pytype пытается сделать именно вывод типов для проверки корректности кода, что есть похвально, но не поможет в REPL, или ту же стандартную библиотеку вывести не сможет из-за слишком размытых типов онной. Взять тот же итератор, который может быть с __iter__, но может быть с __getitem__ — оба варианта корректны для цикла for.
Неужели ни у кого нет никаких идей? Вот например, статичные описания классов позволяют выводить атрибуты у ячеек и проверять корректность работы с объектами по единому интерфейсу, то есть, по ABC-стилю. Если же на каждый объект во время выполнения еще и вешать критерии корректности работы с этим объектом, то можно в специальном режиме отладки увидеть те ошибки, которые в норме ни статические валидаторы, ни сам CPython выловить не смогут. Например, какой-то отбитый код (не метод объекта) решает добавить свой собственный атрибут в объект - по ошибке или из-за плохого стиля. И тогда валидатор сможет выдать предупреждение, мол, «нарушение инкапсуляции». Или в ячейке лежит строка, но какой-то кусок кода может потенциально положить в ячейку массив - вуаля, получите ошибку в консолю. То есть, по сути это то, что делает JIT-компилятор, только на этот раз JIT-компилятор в явной форме высказывает свои возражения по поводу неоптимизируемости куска кода.
Есть смысл для таких танцев заставлять кодеров объявлять переменные динамического типа явно (val1: Any или val1: Union[list,str]), а жестко ограничиваемый статический тип будет выводиться неявно. Естественно, нужно еще переосмыслить само понятие «тип», чтобы под ним подразумевался абстрактный класс, как с тем же итератором, а не конкретный.