[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Tue, Aug 10, 2021 at 3:00 PM wrote: > The history of bytes/bytearray is a dual-purpose view. It can be used in > a string-like way to emulate Python 2 string handling (hence all the usual > string methods and a repr that displays in a string-like fashion). It can > also be used as an array

[Python-Dev] Re: PEP 467 feedback from the Steering Council

I recommend removing the "discouragement" from writing "bytes(10)". That is merely stylistic. As long as we support the API, it is valid Python. In the contexts where it is currently used, it tends to be clear about what it is doing: buffer = bytearray(bufsize). That doesn't need to be

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

On Tue, Aug 10, 2021 at 11:41 AM Jelle Zijlstra wrote: > > > El mar, 10 ago 2021 a las 11:20, Thomas Grainger () > escribió: > >> Although the co_annoations code could intercept the NameError and replace >> return a ForwardRef object instead of the resolved name >> > I implemented a version of

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

Jelle Zijlstra wrote: > El mar, 10 ago 2021 a las 11:20, Thomas Grainger (tagr...@gmail.com) > escribió: > > Although the co_annoations code could intercept the NameError and replace > > return a ForwardRef object instead of the resolved name > > I implemented a version of this in >

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

El mar, 10 ago 2021 a las 11:20, Thomas Grainger () escribió: > Although the co_annoations code could intercept the NameError and replace > return a ForwardRef object instead of the resolved name > I implemented a version of this in https://github.com/larryhastings/co_annotations/pull/3 but Larry

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

Although the co_annoations code could intercept the NameError and replace return a ForwardRef object instead of the resolved name ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

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

> dataclasses need to check for ClassVar Interesting, so the use case we are talking about is: 1) You are using annotations to mean actual types, 2) But you also have to inspect them at runtime, 3) For some of the types the name might not be defined at runtime yet In this example doesn't the

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

Damian Shaw wrote: > > dataclasses need to check for ClassVar > > Interesting, so the use case we are talking about is: 1) You are using > annotations to mean actual types, 2) But you also have to inspect them at > runtime, 3) For some of the types the name might not be defined at runtime > yet >

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

dataclasses need to check for ClassVar ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at

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

On Mon, Aug 9, 2021 at 9:31 PM Inada Naoki wrote: > Currently, reference implementation of PEP 649 has been suspended. > We need to revive it and measure performance/memory impact. I volunteered to check performance impact in practice on the Instagram codebase, which is almost fully annotated.

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

> In this case PEP 649 doesn't help. Sorry for the naive question but why doesn't PEP 649 help here? Is there something fundamental about the dataclass that needs to inspect the type of C.a to create the dataclass? - Damian (he/him) On Tue, Aug 10, 2021 at 1:10 PM Łukasz Langa wrote: > > > On

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

> On 10 Aug 2021, at 13:05, Eric V. Smith wrote: > > If 649 is accepted, there will be few places where stringified annotations > will be needed. For example, forward references that are defined before > __annotations__ is examined will not need to be specified as strings. From > the PEP:

[Python-Dev] Re: New __main__.rst

Huh, distributive pronouns... you learn something every day: https://en.wikipedia.org/wiki/Distributive_pronoun I think I'm just going to change the word "each" to "both", though, because I don't like how "Each of these mechanisms is..." reads. Thank you for the catch @MRAB. On Tue, Aug 10,

[Python-Dev] Re: New __main__.rst

On 2021-08-10 03:14, Jack DeVries wrote: There have been a series of requests to enhance the current __main__.rst document : bpo-17359 bpo-24632 bpo-39452

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

On Tue, Aug 10, 2021 at 5:11 PM Mark Shannon wrote: > > >> > > > > Currently, reference implementation of PEP 649 has been suspended. > > We need to revive it and measure performance/memory impact. > > > > As far as I remember, the reference implementation created a function > > object for each

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

On 8/9/2021 11:25 PM, Inada Naoki wrote: On Tue, Aug 10, 2021 at 12:30 AM Eric V. Smith wrote: Personally, I'd like to see PEP 649 accepted. There are a number of issues on bpo where people expect dataclass's field.type to be an actual Python object representing a type, and not a string. This

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

On 10/08/2021 4:25 am, Inada Naoki wrote: On Tue, Aug 10, 2021 at 12:30 AM Eric V. Smith wrote: Personally, I'd like to see PEP 649 accepted. There are a number of issues on bpo where people expect dataclass's field.type to be an actual Python object representing a type, and not a string.