你们的 Python 代码加不加 Type Hints

[vicalloy]

现在成熟一些的 Python 库都是有 Type Hints 。就我而言，新写的代码基本上都会加。加上后 IDE 可以自动补全，配合 mypy 检查出一些潜在的错误。
在我看来，在程序开始变复杂时，应当让 IDE 和编译器能尽可能的发现更多的问题。如果要用 Python 写一些复杂一些的程序，Type Hints/代码检查/单元测试都是必不可少的。
近期看到有人说“类型注解会增加看代码的心智负担”。感觉就如何注释写多了会增加心智负担一样，无法理解。再者 Python 里大多的类型其实都是可以自动推导，除了函数的输入/输出参数，要手动注明的其实并不多。

如果自己写一些小工具，自然是怎么方便怎么来，Type Hints 加不加都无所谓。如果是给其他人用的公共库，不加 Type Hints 对使用者很不友好。

[mobpsycho100]

稍微复杂一点的程序就要加了, 写 script 一般不加

[zhishixiang]

刚开始写时不知道有这东西，都是一把梭，到后面被教训了才知道有这东西

[roycestevie6761]

必须加，不加代码提示都没有，跟记事本有什么区别

[neutrinos]

不加，想加的话会换一种静态语言

[vialon17]

那肯定要加的，python 之所以被诟病的原因之一就是 type hint ，
而且随着版本迭代升级，py 也逐渐支持 type hint ，能够写的更加清晰明了，
我不知道有什么理由不写。-_-||
ps:现在常用的编译器都支持 py 的类型检测了，写上类型提示后后面再看变量很方便。

[BingoXuan]

加，但 type hints 很废，做不了类型体操

[raptor]

加，加了以后易读性好多了。

[fbichijing]

不喜欢，因为不够简洁。

很多参数看到参数名就能大概知道应该传进什么类型的数值进去，出错的话就 help 看一下函数注释也就知道了。

个人比较喜欢函数注释的那种写法，当有写的必要性时就会加上。就像 requests 里面的

# requests api.py
```python
def request(method, url, **kwargs):
"""Constructs and sends a :class:`Request <Request>`.

:param method: method for the new :class:`Request` object: ``GET``, ``OPTIONS``, ``HEAD``, ``POST``, ``PUT``, ``PATCH``, or ``DELETE``.
:param url: URL for the new :class:`Request` object.
:param params: (optional) Dictionary, list of tuples or bytes to send
in the query string for the :class:`Request`.
:param data: (optional) Dictionary, list of tuples, bytes, or file-like
object to send in the body of the :class:`Request`.
```

[Davic1]

@hsfzxjy 补充一个 pep695 具体变化的讨论贴（个人觉得新手友好一些）

https://www.reddit.com/r/Python/comments/12f3glm/pep_695_type_parameter_syntax_has_been_accepted/

[akaHenry]

Type Hints 是政治正确. (就算很多人日常不加, 恐怕也装装样子鼓励他人加)

Type Hints 当然是好, 但是有开销. (加不加, 加多少, 看具体场景/维护成本/代码生命周期, 以及你和团队会几门语言.)


应该加:

1. 团队(个人) 只会/只用 python 开发, typing 和 Pydantic 都用起来.

2. 单元测试, 写起来, 至少覆盖核心链路. (这比 Type Hints 更容易保障质量和正确使用, 如果时间仅够二选一, 宁愿你写单元测试)


少加/不加: (CPyUG 老炮的场景)

1. 个人项目, 生命周期很短(活不久)的代码. 加了没收益.(怎么快, 怎么来)

2. 多技能栈(Python + Rust, Go 等) 组合. 充分利用动态语言的灵活性, 少加/不加. 需要强约束/性能场景, 直接切 rust/go.

3. 老司机, 写的代码, 可读性好. 加不加, 不影响阅读. (废话, 没有 Type Hints 之前的 10 多年, 大家照样写的飞起)

4. 一次性的脚本, 用完就扔(厕纸代码, 活不过明天). 没必要脱裤子放屁.



个人选择:

1. 作为写了比较久 python 的( py2.5 开始的), CPyUG 说不加 Type Hints 的人不少. 很正常.(在很多场景, 不用, 也都对)

2. 加当然好, 但是要平衡成本和收益. (年轻人, 容易沉迷于写太多没 转化率(不赚钱) 的代码)

3. 我日常会加, 但保持克制. (少用和不用 Pydantic, 有开销).

4. python 已经不是我的主力语言, 用 python 更多是为了快速糊东西和验证技术/产品原型. 一旦验证通过, 很快就会迁移到 rust, go 等重写. 所以, 写 python, 就更追求 怎么快, 怎么来. (代码活不久, 没必要写太好)


以上来自 写了 10 多年 python 的开发者的一点看法.

(当然, mojo 1-2 周, 就要发布了, 喜欢写 Type Hints, 来写 mojo 吧)


免杠指南:

我只是说了 不加/少加 的场景, 你要杠, 你对.

[mywaiting]

话说我用动态语言就是为了写少一点类型声明，为的是粗快猛一把梭！有这觉悟我直接换其他语言了~

[t133]

看到**kwargs 还不注释就想骂娘了

[codeMore]

我们维护的老项目还是基于 python2.7 的呢，不支持

[julyclyde]

没看懂你这句 append 的语气
“水平应该更高才对”似乎暗示了其实并不高？

[julyclyde]

哦哦，明白了“少加/不加: (CPyUG 老炮的场景)”

[jjx]

你喜欢, 你觉得好你就加

但这个同代码可读性完全不能划等号, 否则的话, 静态类型的语言的程序员都是好程序员了?

代码的可读性还是依赖 模块划分, 命名, 代码逻辑清晰表述, 使用大家都明白的设计模式等来达成的

有些人用 python 就是不喜欢脱裤子放屁的场合,比方说, 你明明就知道他的类型, 但一定要写类型(并且强制转换, 静态语言), 结果你一定要他写 python 也是如此, 没有意义

[sordidclown]

个人是加注解的。但是有个问题，假如说不加类型注释，pycharm 在推导不出来类型的时候不会提示属性和方法，也没有检查和补全，这样的话代码写起来不会很难受吗？还是说有其他办法避免这种情况发生？

[tankeco]

遇到最多的问题是，加了 type hints 的代码换了个 python 版本跑不起来…需要我一顿改 tuple 到 Tuple…

[ksc010]

我写的几个项目，从不打算兼容 py2 之后就开始慢慢加了
主要是为了代码提示

[RyougiShiki]

曾经不想把动态语言写的跟 java 一样，我不喜欢 java 才转的 python 也认同 py 的设计哲学。自从用过 FastAPI 后，惊讶于类型注释和由此的参数检查、api 文件自动生成，觉得真方便。现在，我在纯 py 脚本中使用，虽然不会运行时强制，但 pycharm 会检查，相当于方法文档也挺好的。