[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Sat, Apr 24, 2021 at 2:25 PM Larry Hastings wrote: > This is not to say that, in the fullness of time, those objects should > never have annotations. Even in the three random types I picked in my > example, there's at least one example: float.imag is a data member and > might theoretically

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/24/21 8:09 AM, Petr Viktorin wrote: On 24. 04. 21 9:52, Larry Hastings wrote: I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts. The latter was more delicate than the former but

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/24/21 7:11 AM, Nick Coghlan wrote: On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, > wrote: So I now suspect that my knee-jerk answer is wrong.  Am I going too far down the rabbit hole? Should I /just/ make the change for user classes and leave builtin

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 24. 04. 21 9:52, Larry Hastings wrote: I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, wrote: > > So I now suspect that my knee-jerk answer is wrong. Am I going too far > down the rabbit hole? Should I *just* make the change for user classes > and leave builtin classes untouched? What do you think? > I'd suggest kicking the can down

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for both.  I have this much working, including

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/23/21 9:26 PM, Guido van Rossum wrote: This is happening, right? Adding a default `__annotations = {}` to modules and classes. (Though https://bugs.python.org/issue43901 seems temporarily stuck.) It's happening, and I wouldn't say it's stuck.  I'm

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

This is happening, right? Adding a default `__annotations = {}` to modules and classes. (Though https://bugs.python.org/issue43901 seems temporarily stuck.) On Mon, Apr 19, 2021 at 10:10 PM Larry Hastings wrote: > > > As long as I'm gravedigging old conversations...! Remember this one, also >

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

As long as I'm gravedigging old conversations...!  Remember this one, also from January of this year?  Here's a link to the thread in the c.l.p-d Mailman archive.  The first message in the thread is a good overview of the problem:

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 5:53 PM, Ethan Furman wrote: `__prepare__` returns a dict-like namespace that is used as is.  `EnumMeta` uses `__prepare__` to return an instance of `_EnumDict`. When `type.__new__` is called, whatever the namespace used to be is then converted into a normal Python dict, and a

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 5:33 PM, Guido van Rossum wrote: There's a secret though. `cls.__dict__` is not actually a dict -- is a mappingproxy. The proxy exists because we want to be able to intercept changes to class attributes such as `__add__` or `__getattribute__` in order to manipulate the C-level

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Mon, Jan 18, 2021 at 4:34 PM Larry Hastings wrote: > > On 1/18/21 2:39 PM, Guido van Rossum wrote: > > Hm. It's unfortunate that this would break code using what is *currently* > the best practice. > > I can't figure out how to avoid it. The problem is, current best practice > sidesteps the

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 2:39 PM, Guido van Rossum wrote: Hm. It's unfortunate that this would break code using what is *currently* the best practice. I can't figure out how to avoid it.  The problem is, current best practice sidesteps the class and goes straight to the dict.  How do we intercept that

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

Hm. It's unfortunate that this would break code using what is *currently* the best practice. The saving grace seems that for *many* use cases the best practice is to call typing.get_type_hints(). This is particularly useful for classes because it includes annotations from base classes. Also, for

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/18/21 12:16 PM, Guido van Rossum wrote: I do worry about the best practice getting worse if your PEP 649 is accepted. A good part of what motivated me to start this second thread ("Let's Fix ...") was how much worse best practice would become if PEP 649 is accepted.  But if we accept

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Sat, Jan 16, 2021 at 3:32 PM Larry Hastings wrote: > [...] If anybody distinguished between "annotations are unset" and > "annotations are set to an empty dict", that code would fail, but I expect > nobody ever does that. > I agree, since I can't think of differing semantics. Given that

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/16/21 4:09 PM, Greg Ewing wrote: On 17/01/21 12:31 pm, Larry Hastings wrote: Consider the best practice for getting class annotations, example here from Lib/dataclasses.py:     cls_annotations = cls.__dict__.get('__annotations__', {}) Isn't that going to get broken anyway? It won't

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 17/01/21 12:31 pm, Larry Hastings wrote: Consider the best practice for getting class annotations, example here from Lib/dataclasses.py: cls_annotations = cls.__dict__.get('__annotations__', {}) Isn't that going to get broken anyway? It won't trigger the calling of

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/16/21 8:41 AM, Nick Coghlan wrote: Could you get the best of both worlds by making __annotations__ an auto-populating descriptor on "type", the way it is on functions? Continue to add a non-empty annotations dict to the class dict eagerly, but only add the empty dict when

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Wed, 13 Jan 2021, 12:35 pm Larry Hastings, wrote: > > On 1/12/21 5:28 PM, Brett Cannon wrote: > > The other thing to keep in mind is we are talking about every module, > class, and function getting 64 bytes ... which I bet isn't that much. > > Actually it's only every module and class.

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 13/01/21 3:31 pm, Larry Hastings wrote: Let's say we put those behind a from __future__ import.  Now we're gonna write library code that examines annotations. A user passes in a class and asks us to examine its annotations.  The old semantics might be active on it, or the new ones.  How

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Tue, 2021-01-12 at 20:09 -0800, Guido van Rossum wrote: > On Tue, Jan 12, 2021 at 8:00 PM Brett Cannon > wrote: > > > > > * It turns a None annotation into type(None).  Which means now > > > you > > > can't tell the difference between "None" and "type(None)". > > > > > Huh, I wasn't aware of

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Tue, Jan 12, 2021 at 8:00 PM Brett Cannon wrote: > > >>- It turns a None annotation into type(None). Which means now you >>can't tell the difference between "None" and "type(None)". >> >> Huh, I wasn't aware of that. > This has tripped up many people. Maybe we should just bite the

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Tue, Jan 12, 2021 at 6:31 PM Larry Hastings wrote: > > On 1/12/21 5:28 PM, Brett Cannon wrote: > > The other thing to keep in mind is we are talking about every module, > class, and function getting 64 bytes ... which I bet isn't that much. > > Actually it's only every module and class.

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Tue, Jan 12, 2021 at 6:35 PM Larry Hastings wrote: > > On 1/12/21 5:28 PM, Brett Cannon wrote: > > The other thing to keep in mind is we are talking about every module, > class, and function getting 64 bytes ... which I bet isn't that much. > > Actually it's only every module and class.

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/12/21 5:28 PM, Brett Cannon wrote: The other thing to keep in mind is we are talking about every module, class, and function getting 64 bytes ... which I bet isn't that much. Actually it's only every module and class.  Functions don't have this problem because they've always stored

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Mon, Jan 11, 2021 at 5:57 PM Larry Hastings wrote: > > On 1/11/21 5:05 PM, Greg Ewing wrote: > > On 12/01/21 6:22 am, Larry Hastings wrote: > > * The language will set __annotations__ to a dict if the object has > >annotations, or None if it has no annotations. > > > That sounds

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

12.01.21 03:21, Larry Hastings пише: > I forgot about __slots__!  Yup, it's optional, and you can even delete > it, though after the class is defined I'm not sure how much difference > that makes. It affects pickling if __slotnames__ is not set yet. The latter is set when you pickle or copy an

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

Oh, but the behavior of annotations in e.g. mypy is the same. They are cumulative. On Mon, Jan 11, 2021 at 17:42 Larry Hastings wrote: > > On 1/11/21 5:28 PM, Guido van Rossum wrote: > > On Mon, Jan 11, 2021 at 5:21 PM Larry Hastings wrote: > >> Slots intelligently support inheritance, too. I

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 6:31 PM, Greg Ewing wrote: On 12/01/21 2:21 pm, Larry Hastings wrote: Slots intelligently support inheritance, too. Are you sure about that? My experiments suggest that it has the same problem as __annotations__: Python 3.8.2 (default, Mar 23 2020, 11:36:18) [Clang 8.1.0

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 12/01/21 2:21 pm, Larry Hastings wrote: Slots intelligently support inheritance, too. Are you sure about that? My experiments suggest that it has the same problem as __annotations__: Python 3.8.2 (default, Mar 23 2020, 11:36:18) [Clang 8.1.0 (clang-802.0.42)] on darwin Type "help",

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 12/01/21 2:46 pm, Larry Hastings wrote: Using an 64-byte empty dict per object with no defined annotations seems so wasteful.  And anything short of an empty dict, you'd have to guard against. If __annotations__ were to return a read-only mapping object instead of a dict, the same empty

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 6:09 PM, Chris Angelico wrote: On Tue, Jan 12, 2021 at 12:56 PM Larry Hastings wrote: It was a balancing act. Using an 64-byte empty dict per object with no defined annotations seems so wasteful. And anything short of an empty dict, you'd have to guard against. Current code

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Tue, Jan 12, 2021 at 12:56 PM Larry Hastings wrote: > > It was a balancing act. Using an 64-byte empty dict per object with no > defined annotations seems so wasteful. And anything short of an empty dict, > you'd have to guard against. Current code already has to guard against >

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 5:05 PM, Greg Ewing wrote: On 12/01/21 6:22 am, Larry Hastings wrote:  * The language will set __annotations__ to a dict if the object has    annotations, or None if it has no annotations. That sounds inconvenient -- it means that any code referencing __annotations__ has to guard

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 5:28 PM, Guido van Rossum wrote: On Mon, Jan 11, 2021 at 5:21 PM Larry Hastings > wrote: Slots intelligently support inheritance, too.  I always kind of wondered why annotations didn't support inheritance--if D is a subclass of C, why doesn't

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Mon, Jan 11, 2021 at 5:21 PM Larry Hastings wrote: > > On 1/11/21 4:39 PM, Guido van Rossum wrote: > > The easiest thing would be just to create an empty `__annotations__` for > classes that have no annotated variables, and to hell with the cost. > > I assume you'd keep the existing behavior

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 1/11/21 4:39 PM, Guido van Rossum wrote: The easiest thing would be just to create an empty `__annotations__` for classes that have no annotated variables, and to hell with the cost. I assume you'd keep the existing behavior where functions lazy-create an empty dict if they have no

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

Isn't that just typing.get_type_hints()? On Mon, Jan 11, 2021 at 5:11 PM Greg Ewing wrote: > On 12/01/21 6:22 am, Larry Hastings wrote: > > * The language will set __annotations__ to a dict if the object has > >annotations, or None if it has no annotations. > > That sounds inconvenient --

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 12/01/21 6:22 am, Larry Hastings wrote: * The language will set __annotations__ to a dict if the object has   annotations, or None if it has no annotations. That sounds inconvenient -- it means that any code referencing __annotations__ has to guard against the possibility of it being

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

I think your analysis of the problems is great. I don't worry about people deleting `__attributes__` (and those that do can switch to calling its .clear() method instead) but I worry about people not expecting to get None. So if you can avoid that in your solution that would be great. The easiest

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

At last, a nibble on the other fishing line! ;-) On 1/11/21 1:47 PM, Brett Cannon wrote: So the biggest potential breakages are code that: 1. Directly get the attribute from __dict__ 2. The fact that it would no longer be inherited Am I missing anything else? Those are the big ones, the

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On Mon, Jan 11, 2021 at 9:23 AM Larry Hastings wrote: > [SNIP - background info] > > > If I could wave my magic wand and do whatever I wanted, I'd change the > semantics for __annotations__ to the following: > > * Functions, classes, and modules always have an __annotations__ member > set. > *

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

My code pretty much does what you suggest at the end of your message: On Mon, 2021-01-11 at 09:22 -0800, Larry Hastings wrote: > Or code can just use inspect.get_type_hints(), which is tied to the > Python version > anyway and should always do the right thing. So far, this has proven mostly[1]