Best Practices for Using Types

[shenxiangzhuang]

using mypy for now

Q1. Is it a good choice to wrap all the types with domain alias? For example, we have many machine learning models parameters which are float or int, should we define Parameter = Union[int, float], or Number = Union[int, float] with Parameter = Number?

Q2. If we have many self-defined types, how to manage them in a better way? Make every machine learning model has it's own domain types is good choice or not? For example, in Model-A, we have Parameter = Union[int, float] and Union[int, float] has another meaning in Model-B with Value = Union[int, float].

[shenxiangzhuang]

For reference(thx @ZhiyuanChen for his help):

• PEP3141
• PEP544

[shenxiangzhuang]

Fro reference:

• https://github.com/pyecharts/pyecharts/blob/master/pyecharts/types.py
• https://github.com/tiangolo/fastapi/blob/master/fastapi/types.py

[aisk]

using mypy for now

Q1. Is it a good choice to wrap all the types with domain alias? For example, we have many machine learning models parameters which are float or int, should we define Parameter = Union[int, float], or Number = Union[int, float] with Parameter = Number?

Q2. If we have many self-defined types, how to manage them in a better way? Make every machine learning model has it's own domain types is good choice or not? For example, in Model-A, we have Parameter = Union[int, float] and Union[int, float] has another meaning in Model-B with Value = Union[int, float].

For this specified purpose, you can just use float instead of Union[int, float]. More details: https://peps.python.org/pep-0484/#the-numeric-tower

For other purposes, such as when the argument may be a string or a float, you can use a: float | str. It's very concise and easy to read. However, be aware that this syntax was introduced in later versions of Python. For more complex scenarios or when the parameter type has some well-known abstractions, like it being a Point rather than just a (x, y), you may define specific types for the arguments, but I think there may not have a definitive answer.

[shenxiangzhuang]

@aisk Thank you for your suggestions which help a lot! This is the first time I've seen the numeric tower! And I agree that the answer to this question depends on many factors. I think these "well-known abstractions" with some domain specific considerations maybe the right approach.

I think the trade off maybe key point here: too many domain specific defined types(like Value = float | str may lead to lots of self-defined types which may hurt readability finally?) and some complicated types(nested types for example) should be extraced for concise. I will try to do some practices in this project later.

Thank again for your help!

[ZhiyuanChen]

using mypy for now

Q1. Is it a good choice to wrap all the types with domain alias? For example, we have many machine learning models parameters which are float or int, should we define Parameter = Union[int, float], or Number = Union[int, float] with Parameter = Number?
Q2. If we have many self-defined types, how to manage them in a better way? Make every machine learning model has it's own domain types is good choice or not? For example, in Model-A, we have Parameter = Union[int, float] and Union[int, float] has another meaning in Model-B with Value = Union[int, float].

For this specified purpose, you can just use float instead of Union[int, float]. More details: https://peps.python.org/pep-0484/#the-numeric-tower

For other purposes, such as when the argument may be a string or a float, you can use a: float | str. It's very concise and easy to read. However, be aware that this syntax was introduced in later versions of Python. For more complex scenarios or when the parameter type has some well-known abstractions, like it being a Point rather than just a (x, y), you may define specific types for the arguments, but I think there may not have a definitive answer.

float | str is identical to Union[float, str]. While the first syntax is only introduced in python 3.10, it can be used in previous python version (3.8+) if you from __future__ import annotations