Nikita Sobolev <m...@sobolevn.me> added the comment:
Thanks, Guido! > Yes, it is too late for 3.10 (but you can add it to typing_extensions). Also, > PEP 585 is done, we don't update PEPs. Got it! > Please do test with `from __future__ import annotations` -- you never know. Done, PR is updated. Now we test that `property` works with future import. > When this was first proposed (https://github.com/python/typing/issues/985) > there were worries about backwards compatibility. Given how common property > is, we need to make sure there are no problems with that. Can you address > that? I don't see it in the original thread. I guess you were thinking about this one: https://github.com/python/typing/issues/594 Here's a list of problem from the original thread: ## the returned value of property has no typing equivalent Now there is: `property[G, S]` ## There is no consistency in how properties in classes work in comparison to normal variables or functions Author points out that all python versions right now ignore `property`s when `get_type_hints()` is used. There's nothing we can do here: it is not related to `property`s being generic in any way. Here's how it works before my patch: ```python Python 3.10.0 (default, Nov 1 2021, 10:24:06) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from typing import get_type_hints >>> class Some: ... @property ... def a(self) -> int: ... return 1 ... >>> get_type_hints(Some) {} >>> get_type_hints(Some.a) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/typing.py", line 1827, in get_type_hints raise TypeError('{!r} is not a module, class, method, ' TypeError: <property object at 0x102b7a7f0> is not a module, class, method, or function. ``` I've added a test case for my patch to make sure this behavior is not changed. And indeed, it works exactly the same as before. I've also covered a part from https://github.com/python/typing/issues/594#issuecomment-627692188 Runtime introspection of `fget` / `fset` / `fdel` works the same as before. I've added a test case for this. ## Forward compat Users of python<3.11 will have `property` with `[]` type syntax via `typing_extensions`. I don't think it is going to be widely used, though. > Also, since this requires type checkers to change, do we need a PEP? I cannot speak for all type-checkers, but I know how it works in mypy. Mypy already supports descriptors. So, this example works: ```python class Desc: def __get__(self, obj, typ) -> int: pass class Some: a = Desc() s = Some() reveal_type(s.a) # N: Revealed type is "builtins.int" reveal_type(Some.a) # N: Revealed type is "builtins.int" ``` The same just works for my `property` stub example from https://github.com/python/typing/issues/985 All in all, I don't think that we need a PEP for three reasons: 1. properties are already supported in all type checkers (with special casing), if it does not cause any trouble, existing behavior can be left untouched. Mypy has multiple problem with our special casing 2. Underlying mechanism - which are descriptors - is also supported 3. Change is relatively small, it does not add any new concepts Feedback on this is welcome! Maybe I am missing something. > Honestly I think it's too soon for a PR given that we don't seem to have > agreement in the typing tracker discussion. This PR is really small. It took me like 30 mins, but we have a reference now. We can close it anytime with no damage done! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46162> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
