[Python-Dev] Re: Problems with dict subclassing performance

No ideas? Excuse me for the up. On Fri, 6 Aug 2021 at 21:29, Marco Sulla wrote: > > I've done an answer on SO about why subclassing `dict` makes the > subclass so much slower than `dict`. The answer is interesting: > > https://stackoverflow.com/questions/59912147/why-does-subclassing-in-python-sl

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Thu, Aug 12, 2021 at 3:01 AM Larry Hastings wrote: > > On 8/11/21 5:15 AM, Chris Angelico wrote: > > On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: > > This approach shouldn't break reasonable existing code. That said, this > change would be observable from Python, and pathological c

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, Aug 11, 2021 at 2:13 PM Barry Warsaw wrote: > As for the second question, it means that we have to be very careful that the > folks who use type annotation at compile/static checking time (e.g. mypy and > friends) explicitly consider the existing use cases and needs of the runtime > typ

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

Yes, I think we should get it done by b1. For some reason it never occurred to me to add this to What's New. Someone just reported this on bpo this week. I'll try and get a PR together this week. Eric (who doesn't feel picked on!) On 8/11/2021 2:35 PM, Brett Cannon wrote: Not to specifically p

[Python-Dev] Should we try to get a complete draft of What's New by b1?

Not to specifically pick on Eric V. Smith, but yesterday a co-worker came to me asking about `KW_ONLY` for dataclasses and wanting to provide feedback ( https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY). I said we had reached RC and so it was pretty much too late; the alpha

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/2021 11:07 AM, Jukka Lehtosalo wrote: On Wed, Aug 11, 2021 at 2:56 PM Thomas Grainger > wrote: Would: ``` @dataclass class Node:     global_node: __class__ | None ``` "Just work" with co_annotations? This feels too specialized to m

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Aug 9, 2021, at 08:27, Eric V. Smith wrote: > > My understanding is that PEP 649 is currently in front of the SC. But do we > need to have any additional discussion here? My recollection is that we > backed out the PEP 563 change because we didn't feel we had enough time to > come to a good

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

I don't think I've seen code like this. It would be incredibly useful to have a cpython-primer (like mypy-primer and black-primer) that ran as many test suites as possible from pypi with every cPython commit ___ Python-Dev mailing list -- python-dev@pyt

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 5:15 AM, Chris Angelico wrote: On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: This approach shouldn't break reasonable existing code. That said, this change would be observable from Python, and pathological code could notice and break. For example: def ensure_Foo_is_a_cl

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/2021 7:56 AM, Larry Hastings wrote: So, here's an idea, credit goes to Eric V. Smith.  What if we tweak how decorators work, /jst slghtly/, so that they work like the workaround code above? Specifically: currently, decorators are called just after the function or class object

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, Aug 11, 2021 at 7:09 AM Larry Hastings wrote: > On 8/10/21 11:15 AM, Thomas Grainger wrote: > > Although the co_annoations code could intercept the NameError and replace > return a ForwardRef object instead of the resolved name > > > No, it should raise a NameError, just like any other P

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, Aug 11, 2021 at 2:27 PM Guido van Rossum wrote: > As it happens, I have a working prototype of lazy in marshaling that would > work well for this. > > Nice to see you keep the time machine in working order ... Kind regards, Steve ___ Python-Dev

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, Aug 11, 2021 at 2:56 PM Thomas Grainger wrote: > Would: > ``` > @dataclass > class Node: > global_node: __class__ | None > ``` > > "Just work" with co_annotations? > This feels too specialized to me. It would be great to also handle forward references to other classes and cyclic ref

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

Would: ``` @dataclass class Node: global_node: __class__ | None ``` "Just work" with co_annotations? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lis

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

Oh, I agree it shouldn’t reference the typing module. But it should not raise NameError. This whole thing already is a special case. We can debate what else it should, e.g. skip the name, return a fixed error token, return an error token that includes the name that failed (this is part if the NameE

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

As it happens, I have a working prototype of lazy in marshaling that would work well for this. On Wed, Aug 11, 2021 at 06:07 Larry Hastings wrote: > On 8/11/21 5:21 AM, Inada Naoki wrote: > > But memory footprint and GC time is still an issue. > Annotations in PEP 649 semantics can be much heavi

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

Larry Hastings wrote: > On 8/11/21 2:48 AM, Jukka Lehtosalo wrote: > > On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger > mailto:tagr...@gmail.com> wrote: > > Larry Hastings wrote: > > > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > > > I think as long as there's a test case for something like >

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 5:21 AM, Inada Naoki wrote: But memory footprint and GC time is still an issue. Annotations in PEP 649 semantics can be much heavier than docstrings. I'm convinced that, if we accept PEP 649 (or something like it), we can reduce its CPU and memory consumption. Here's a slightly c

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

> 2021/08/11 19:22、Paul Moore のメール: > > Also, I don't think that improving performance is a > justification for a non-trivial backward compatibility break (I don't > recall a case where we've taken that view in the past) so "PEP 649 > solves forward references without a backward compatibility imp

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: > Specifically: currently, decorators are called just after the function or > class object is created, before it's bound to a variable. But we could > change it so that we first bind the variable to the initial value, then call > the decor

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 2:48 AM, Jukka Lehtosalo wrote: On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger > wrote: Larry Hastings wrote: > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > I think as long as there's a test case for something like > > @dataclass > >

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, 11 Aug 2021 at 07:37, Larry Hastings wrote: > [...] > I think PEP 649 should be considered in the same way. In my opinion, the > important thing is to figure out what semantics we want for the language. I think this is a very important point. As originally implemented, annotations allow

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger wrote: > Larry Hastings wrote: > > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > > I think as long as there's a test case for something like > > > @dataclass > > > class Node: > > > global_node: ClassVar[Node | None] > > > left: InitVar

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

Larry Hastings wrote: > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > I think as long as there's a test case for something like > > @dataclass > > class Node: > > global_node: ClassVar[Node | None] > > left: InitVar[Node | None] > > right: InitVar[None | None] > > > > the bug http

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 12:02 AM, Thomas Grainger wrote: I think as long as there's a test case for something like ``` @dataclass class Node: global_node: ClassVar[Node | None] left: InitVar[Node | None] right: InitVar[None | None] ``` the bug https://bugs.python.org/issue33453 and the curren

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

I think as long as there's a test case for something like ``` @dataclass class Node: global_node: ClassVar[Node | None] left: InitVar[Node | None] right: InitVar[None | None] ``` the bug https://bugs.python.org/issue33453 and the current implementation https://github.com/python/cpyth