INADA Naoki <songofaca...@gmail.com> added the comment: > > I think we've learned lesson that we shouldn't use typing in modules other than typing...
> This is a blanket statement that as hurtful as it is factually incorrect. Let me address the latter. > 1. Dataclasses are entirely dependent on annotations *as described by the typing module*. While it would be entirely possible for users to pass an arbitrary expression as an annotation to denote it's a field of the dataclass, then it's confusing the reader of that code... what's the point? The fact that dataclasses isn't itself importing `typing` is an implementation detail of dataclasses. When I said "use typing module", I meant "using type information from annotation value" preciously. Using only name of the annotation is not harmful. > 2. The problem isn't even specific to `typing` but stringified type annotations in general. If the magic sentinel annotation came from the dataclasses module, it would be just as tricky to get it right as it is now when this sentinel lives in `typing`. Yes. I think we shouldn't parse annotation value until we can expect issues like this and estimate performance overhead of massive calling of get_type_hints() on application startup. > 3. singledispatch now also allows registering functions that are type-annotated. In fact, that is a nicer API than the old one. That usage also imports `typing`. I don't see how this is a problem. How about performance? Isn't performance overhead of it is much larger than expected by people who don't know internal of get_type_hints()? I agree that annotation could very useful. But I fear that utilizing annotation value may make ugly hack like "ClassVar" prefix or unexpected slow import time. So I want to be very conservative about utilizing annotation in stdlib. Once it is happen, it's very hard to remove it from stdlib. I think we should learn more about runtime usage of type hints in third party library, before using it in stdlib. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33453> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
