[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Looks like no one showed much interest in it :(
So, yeah, closing it is probably the best idea.

Thanks everyone!

--
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Guido van Rossum]

Guido van Rossum  added the comment:

Since the conclusion is that we can't do this without breaking backwards 
compatibility, should we just close this? Or is there still a compromise 
possible?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Serhiy, no, we can infer that.

There are two general cases:

1. `x = property(x_get, x_set)`, it is just ideal
2. `@property x` and `@x.setter`, it is also inferable with a bit of special 
casing for the mutable type part (we mutate the type of `x` when adding a 
setter)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +AlexWaygood

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Marc Mueller]

Change by Marc Mueller :


--
nosy: +cdce8p

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Does it mean that property[GetType, SetType] will be required and MyPy will 
complain if the raw property decorator be used?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Nikita Sobolev  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 "", line 1, in 
  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:  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Guido van Rossum]

Guido van Rossum  added the comment:

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. Please do test with `from __future__ 
import annotations` -- you never know.

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.

Also, since this requires type checkers to change, do we need a PEP?

Finally. Please keep discussion in this bpo issue, don't have long discussions 
on the PR. (Honestly I think it's too soon for a PR given that we don't seem to 
have agreement in the typing tracker discussion.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Change by Nikita Sobolev :


--
keywords: +patch
pull_requests: +28460
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30238

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Nikita Sobolev  added the comment:

One more question about PEP585: it does not specify `property`. Do we need to 
update it?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

New submission from Nikita Sobolev :

Original discussion in `typing` bug tracker: 
https://github.com/python/typing/issues/985

Short description:
- `property[GetType, SetType]` is required for us to remove a lot of special 
casing from type-checkers and just use the primitive type
- In runtime it copies the same behavior `list` / `dict` / other primitive 
types have under PEP585

Open questions:
- I think that it is too late to backport this in 3.10. Am I right?
- I hope that `from __future__ import annotations` will just work for this new 
change. Is there anything I should do in scope of this PR? Is my assumption 
about `__future__` import is even correct in this context? Do I need to test 
that it works with `__future__ annotations`?

--
components: Library (Lib)
messages: 409080
nosy: gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: Make `builtins.property` generic
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com