大家现在写 Python , 用类型注解吗

第三种吧，对于一些没注解的第三方函数会给变量加注解

函数入参/返回值

入参、出参会注解一下，反正以前也要写 docstring ，直接写注解 docstring 就不需要写类型了，挺方便的

能用就用，主要是 pyright 跟踪比较方便
但 Union 这种就不想写了，还要 import

函数都写，变量不一定。
加了注解后 IDE 更智能，而且配合 mypy 可以检查出不少问题。

说实话，很浪费时间，虽然严谨一点，但是很影响效率。如果是公司的项目有要求，我会写，但是自己的项目绝对不写，Python 的优势本来就是灵活、快

第三种

如果想要类型安全，为什么不直接用静态类型语言

最好函数入参返回都写.

在别人的开源项目上加功能. 结果函数名写的复数, 入参既有 str 又有 list, 难绷.

intelligence 不能推导出类型的就写

自己的项目第二种，公司项目第四种

放弃了，根本写不明白，Union 满天飞，Dict 里面到底是啥，各种 Callable ，更别提 *, ** 的转发了。

@Hopetree 这个就是个平衡

写代码时候麻烦点, 为的是以后减少错误, 或 debug 等等耽误的时间, 所以如何平衡也是个人的方式

想起来就写，主要是为了 IDE 的自动补全

用 不用过两天就忘了自己写了个啥了

很难想象多层复合类对象，类中的属性又是其他的类对象，其他类对象又引用了别的对象，不用类型注解写代码没有联想的痛苦

用，并且配合 pydantic ，简直爽歪歪

都说 Python 灵活，写类型提示也可以灵活点，做二极管大可不必。

一次性脚本就根据需要 IDE 提示的地方写一下，比如字典取对象，写个提示方便后面代码编写。
验证的小项目参考上面，然后函数出参入参写一下。
如果是自己会长期维护，或者必然时间很久之后要修，那就能写的地方就写一下，之后再来看代码就好受点。

寫，因為用 IDE 和各種靜態工具爽。另外就是不寫的話，以後回來看就是火葬場。接手了別人的代碼，什麼類型都沒寫，各種入參完全不知道是什麼鬼，費了一堆時間在猜。

第三种

借个楼，各位写 typehint 的时候遇到异步生成器函数没有实现的的情况下如何处理的

异步生成器，即函数体有 yield 的异步函数，没有实现即它的具体实现在子类中，父类仅仅提供一个接口。如果使用诸如 mypy 这样的严格静态类型检查器，只写个 pass ，因为没有 yield 语句，mypy 就会认为返回类型不是生成器所以报错

我想到了一个办法就是 yield from 这个函数自己，让 mypy 自己绕圈去，但感觉不够优雅，说到底还是破坏了可读性，用 pass 可以表示函数体为空，没有逻辑。而 yield from 有迷惑性

@vituralfuture #21

def f():
... return
... yield

@vituralfuture #21 不對啊 具體實現在子類的話, 直接 @abstractmethod 不就完事了麼

都写注解了 我为什么不用 golang

最开始是一点不用。那时 py , Ruby, js ，更习惯于 duck type 。

后来习惯了 Kotlin, Go ，现在尽量全部用。

用，而且我规定公司所有 Python 项目都得用

用 AI 加类型提示

一个直观的体验提升：写类型注解可以帮助 IDE 进行更好的静态分析，从而提升补全等功能的体验

response: str = "写，都写，不然就是 “不写一时爽，维护火葬场”"
print(response)

工作代码用,自己用的代码从来不写.

比 2 强比 3 差。。。基本重要的都会用

有了那么好的 TS ，还是不少人喜欢无类型的 JS ，py 一样的 ～

跟 TS 、JSDOC 一样，编辑器能自动推导的类型不写，只写不能自动推导的类型。
因为编辑器提供智能提示，非常爽。?

v1 = 'string' # 这里不写
v2 = 1 # 这里也不用写

def func(arg: SomeType) # 参数不能自动推导，要写。返回值能自动推导，不写。

@vituralfuture #21 你要做的应该是个抽象类，不如直接用 abc.ABCMeta 作为父类的元类， @ abc.abstractmethod 装饰这个方法，代码块里 raise NotImplementedError ，反正抽象类也不能直接初始化。mypy 也应该识别得到这种情况。

写，检查工具也用上

我觉得有点复杂的是那种库里头的类型，有时候需要写成 abc.cde.deg 这种一长串——当然可以通过 import 来解决，但是还是觉得很麻烦。C 就没这个问题。

不用，给自己套枷锁干啥

ide 不能自动提示的时候写

无所谓，反正就是按个 Tab 的事情，打个冒号/横杠给 AI 起个头，AI 就会自己解决这个问题，基本不需要费脑子人工调整。除了那种封装的比较深的框架里的东西 AI 都搞不明白要标啥的以外，其他东西基本都顺手就标了注解。

写不写都行，反正都能运行，不是太想写

不写，因为不好看。有点背离写 Python 代码简洁的初衷。
根据必要程度从低到高我一般会划分为以下几类：
1. 通过变量命名，比如(datalist)之类；
2. 在函数注解中标明；
3. 通过 if 对变量类型进行判断，或 raise Error ，或可传入不同类型来获取结果，常面对的场景就是可传文件或者字符串；
4. 某些特殊情况下通过 assert 卡住过往的值。
没错，就是不想写。因为敲起来很麻烦。看起来感觉不够简洁，不美。
个人之见。

用啊，因为 copilot 自己就会带出来

不写 python 了，写 go ，哈哈

python 中装饰器挺常见的，我发现给装饰器写个类型注解还是挺困难的。

主要的困难点在于，要求装饰器修饰的函数，类型要一致。多人开发的时候，这个保证有点难。

用， 谁用谁爽

先不写，然后 Ai 补全自动处理

写，目标是 vscode 开 basic 检查不报红
但是 vscode 里面的类型检查还是有不少 bug 的，复杂一点的类型体操就有可能出问题，也是无奈

第三种，函数用。

需要 code review 的写，不需要 code review 的不写

之前全用，现在写的一个项目要编译成 c ，如果类型注解写的不准确运行到这块的时候会报错，就很无语，导致现在这个项目的类型注解写的很谨慎

看来大家都一样嘛。 我是函数中参数不能一眼看出来的就写。。没有智能提示的也写。方便自动提示。

函数, 变量所有全部用； 写完之后 pycharm 联想很舒服

第四种,除非:
一眼就能看出什么类型的变量和根本找不到具体类型的变量(来自其他库的返回值)

写，不过高阶函数那个 Callable 写着真恶心，我的感觉是 python 的类型推导太弱了，有些情况 typehint 写起来比静态类型还麻烦

@NoOneNoBody #4 3.12 省事了很多，Union[list, None] 可以直接写成 list|None