Vincent

是在注释里的类型注解还是在参数后面？ 注释里面: ``` """ :param username: 用户名 :type username: str """ ``` 如果是参数后面的话： ``` def func(username: str) -> None: pass ```

> https://www.python.org/dev/peps/pep-0484/ 谢谢，起初我还在犹豫，因为typing是在3.5版本引入的

有一个想法，可以使用[stub files](https://www.python.org/dev/peps/pep-0484/#id44)来实现类型注解，这样可以在不修改原py代码的情况下实现类型注解，而且可以最大程度保证了代码的整洁（考虑到API接口的返回值类型可能需要写大量的`typing.TypedDict `，可能会让代码变得不容易阅读）。 下面是我尝试写了一段`wechatpy.client.base.py`的类型注解内容: ```python # 文件路径: wechatpy/client/base.pyi import logging from typing import TypeVar, Any, Type, Optional, Union, Callable, NoReturn from requests import Response from wechatpy.session import SessionStorage _T =...

这是使用`typing.TypedDict`来注解返回值类型的效果  

> @huimingz 返回值的问题，如果能尽可能使用 dataclasses，应该不需要用 TypedDict 尝试了使用dataclasses来处理返回值，考虑到与之前的兼容性问题，将自定义的类继承自`collections.abc.Mapping`，在保持了原有的一些字典特性（比如使用下标的方式获取值）的同时，还支持点语法获取指定的值，确实方便不少。 不过考虑到之前的部分用户会将该返回值直接进行JSON等序列化操作，会出现一些和之前不一样的情况。 拿JSON序列化举例，在序列化时出现了失败的情况，需要在`dumps`时指定`default`来解决，但这会破坏已有的代码。有没有办法在不破坏已有用户已有调用方式的情况下来实现呢？另外用户可能还利用了一些其它`dict`的特性也说不定，目前我没有想到有效的使用dataclasses的方法。 下面是一段演示代码: ```python import json from collections.abc import Mapping from dataclasses import dataclass from typing import Any @dataclass class Invoice(Mapping): errcode: int errmsg:...

> 既然是在 2.x 这个事情，那有些 breaking change 没关系的，用户的负担就是增加个 `dataclasses.asdict(res)` 转换一下 如果这样的话还是尽量继承`collections.abc.Mapping`类，兼容原有的字典类型的一些特性。那么，就没必要使用`stub files`来进行类型注解了，也可以防止在进行接口新增和修改时需要维护两个文件。 关于dataclasse类的存放路径，有什么建议吗？比如单独建立一个模块，或者存放至对应的模块中等

@messense 建议更改为`models`吧，我建议放到和api目录同级的目录，比如微信公众号下接口`models`，目录应该时在`wechatpy/client/models.py`。企业微信的`models`在`wechat/work/client/models.py`。 另外一个需要考虑的问题就是如果使用单个文件`models.py`来存储所有的`dataclass`类，可能会出现较为臃肿的情况，需不需要考虑使用包的方式，比如以下结构： ``` models/ ├── __init__.py ├── message.py ├── tag.py └── user.py ``` 当然这样也存在缺点，增加了项目文件等。

@messense 先做一个看看吧，需要的话再进行分层