Как правильно узнавать типы данных (из внешних пакетов) для объявления своих функций?

Question

[Ярослав]

По-хорошему принято указывать типы для всех аргументов функций.
Но вот, допустим, есть у нас скрипт, который работает с SQLAlchemy с банальным кодом вроде:

engine = create_engine(args.db)

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

Если я печатаю type(engine) то я узнаю: sqlalchemy.engine.base.Engine
ChatGPT советует - sqlalchemy.engine.Engine
хелп в VSCode говорит - "Create a new _engine.Engine instance."
при этом часто ведь возвращаемый тип может быть разным (например, можно допустить что в альтернативном пакете для mysql и для postgresql сами типы могут быть разные, но от общего предка). То есть, я не могу использовать то, что мне type() выдал.

Как при работе с незнакомым пакетом правильно определить, какой тип использовать? Есть какой-то единый прямой каноничный способ?

Comments

[Everything_is_bad]

зачем тут тег Программирование?

[Everything_is_bad]

Если я печатаю type(engine) то я узнаю: sqlalchemy.engine.base.Engine
ChatGPT советует - sqlalchemy.engine.Engine
хелп в VSCode говорит - "Create a new _engine.Engine instance."

так везде же Engine, проблема не понятна, какой импотируешь, тот и используй

[Wispik]

например, можно допустить что в альтернативном пакете для mysql и для postgresql сами типы могут быть разные

Какая разница альтернативный пакет или нет. Алхимия для этого и создана, чтобы со всем работать одинаково.
В данном случае create_engine всегда будет возвращать Engine

[Ярослав]

Everything_is_bad, Wispik так разные же Engine. Даже если они одинаковые, есть разные символы:
- sqlalchemy.Engine
- sqlalchemy.engine.Engine
- sqlalchemy.engine.base.Engine

Чтобы узнать, разные или нет - надо полазить по исходникам. Неужели это правильный путь?

и еще, наверное, есть какой-то _engine.Engine откуда-то, я даже не нашел откуда.

Пусть даже в нашем частном случае (с sqlalchemy) - все они указывают на один класс, как определить какой из них правильнее?

Мне интересно не с этим конкретным типом разобраться, а с общим правилом. Есть некоторая функция F из пакета P, какой тип использовать для того значения, которое она возвращает?

[Wispik]

Ярослав,

так разные же Engine

они одинаковые, просто импортированы из разных мест

Чтобы узнать, разные или нет - надо полазить по исходникам.

не может быть в рамках одной библиотеки несколько разных классов с одним названием

В целом проблема не понятна. Просто посмотреть, какой тип возвращает функция F (для этого не обязательно в исходники лезть, IDE все отлично показывает)

Answer 1

[Aragorn]

Во-первых, зачем париться с типами
Во-вторых, я всегда указываю (когда указываю) тот тип, который возвращается (sqlalchemy.engine.Engine) или тот, от которого наследуется.
В-третьих, ни о каких каноничных стандартах, кроме PEP, я не слышал

Comments

[Ярослав]

а откуда вы узнали, что возвращается sqlalchemy.engine.Engine ? Потому что мне type вернул чуть другое:
sqlalchemy.engine.base.Engine

каждый раз смотреть паренты, паренты парентов и интуитивно угадывать, где нужно остановиться?

[Aragorn]

Ярослав, в ide типа vscode и pycharm при наведении на функцию показывает, что она возвращает

Answer 2

[Everything_is_bad]

так разные же Engine. Даже если они одинаковые, есть разные символы:
- sqlalchemy.Engine
- sqlalchemy.engine.Engine
- sqlalchemy.engine.base.Engine

Чтобы узнать, разные или нет - надо полазить по исходникам. Неужели это правильный путь?

вот сразу заблуждение что они разные, отсюда вытекает полное непонимание.

Какой правильно из этих - да куча вариантов, открыть доки и почитать как принято (обычно более короткий путь), исследовать исходный код тоже хороший вариант, особенно когда там уже аннотировано, а если нет, то поставить stubs пакет, у большинства популярных он есть, pip install sqlalchemy-stubs, ну и при наличия аннотаций IDE тебе будут выводить верные подсказки (хотя и без них тоже уже давно умеют)