Labyrinth: расписать типы классов и функций

[lounres]

Расписать у методов классов и других функций типы аргументов и возвращаемых значений. Возможно, стоит использовать нотацию через *.pyi.

[gtivansan]

Возможно, стоит использовать нотацию через *.pyi.

А что это?

[lounres]

Это прикольная вещь. Чтобы разные среды и питон работали лучше (не знаю чем это хорошо питону, но пишут, что лучше становится; а в поисках ошибок это точно помогает: проверено), можно у всех необходимых переменных определить их тип, а у всех необходимых функций - типы их аргументов и тип возвращаемого значения. Например можно написать так:

class LabyrinthObject:

    _lrtype = 'labyrinth_object'  # type: str

    ...

    def have_flag(self, flag_name: str) -> bool:
        return flag_name in self.flags

Здесь у переменной _lrtype мы кроме определения значения задали ещё и её тип (str), а у функции - кроме самого её объявления мы показали, что она принимает (не считая себя, конечно) строковое значение, а выдаёт булево.

Да, пример для переменной выглядит абсурдно: про строку и так понятно, что она строка. Более лучшим примером, например, может послужить часто встречающаяся строка

health = self.labyrinth.get_unique('health')

По своей природе .get_unique может выдать всё, что угодно (экземпляр (под)ⁿкласса (for some non-negative integer n) LabyrinthObject, конечно). Но здесь мы можем показать, что это именно переменная класса Health:

health = self.labyrinth.get_unique('health')  # type: Health

Это полезно, например, чтобы всевозможное ПО могло понять, что у него есть объект, который обладает кучей крутых методов, и понятно, что они получают и выдают (выглядит как зацикливание, не так ли?).

Также это можно делать двумя способами: в самом файле (1) или в отдельном файле с тем же названием, но с расширением .pyi (2):
(1)
random_file.py:

def random_function(random_argument: str) -> List[str]:
    return random_argument.split('15')

(2)
random_file.py:

def random_function(random_argument):
    return random_argument.split('15')

random_file.pyi:

def random_function(random_argument: str) -> List[str]: ...

Разбиение на части очень удобно, когда у тебя имеются громоздкие функции с большим количеством аргументов. Иначе по-моему лучше первое.

По этому я нашёл официальные материалы:
(1) PEP 484 -- Type Hints
(2) typing — Support for type hints — Python 3.7.3 documentation

К сожалению, из-за языкового барьера у меня не получается это понять, поэтому я быстро закончил с этим (хотя я переработал почти весь labyrinth_engine). Ветка LR-typisation сейчас валяется здесь, на GitHub, если надо.

[gtivansan]

Вроде понятно. Возможно полезно.

Я знаю, что такой способ описания типов используют всякие IDE. А для чего ещё это нужно? Я не понял. Есть какие-то программы для анализа?

Про pyi. Раз уж сделал, то ок. Но главное не позиционируй всю эту псевдо-типизацию в приоритет.
Мы, и куча других людей жили без неё и не тужили, а использовать новшества только, потому что "Круто! Нам это обязательно нужно!" - плохой вариант.

Чисто моё мнение по этому вопросу. Без разделения на два файла - ок. Вроде полезно т.к. иногда что-то становится понятнее.
С разделениями на файлы - какой-то цирк. Несмотря на то, что это есть в PEP, это какая-то антипитонщина. Он же изначально динамически-типизированный язык. Зачем тащить в него фишки из строго-типизированных языков?

Главный message - подумай про то, действительно ли это нужно, что стоит тратить на это силы.
Если да, то пожалуйста.

[lounres]

Про pyi. Раз уж сделал, то ок. Но главное не позиционируй всю эту псевдо-типизацию в приоритет.
Мы, и куча других людей жили без неё и не тужили, а использовать новшества только, потому что "Круто! Нам это обязательно нужно!" - плохой вариант.

Я делаю это по той причине, что моя IDE тупит без этого, и поэтому я не могу с лёгкостью делать очень приятные вещи. Например, IDE иногда просто не понимает, что тот или иной аргумент - это Лабиринт, поэтому ничего не может подсказывать или проверять. А хотелось бы...

С разделениями на файлы - какой-то цирк. Несмотря на то, что это есть в PEP, это какая-то антипитонщина. Он же изначально динамически-типизированный язык. Зачем тащить в него фишки из строго-типизированных языков?

Ну на самом деле на интерпретацию эти файлы не влияют. И плюс объявление, например, : Any строгой типизации не даёт (вообще совсем). Это всё ещё нестрогая типизация.

Главный message - подумай про то, действительно ли это нужно, что стоит тратить на это силы.
Если да, то пожалуйста.

Понятное дело. Я пока что делаю их, если не возникает проблем. И только чтобы потом было (мне) комфортнее. Но вот давно возникла проблема и я забил, пока не сяду и не разберусь (походу не скоро).