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

On Fri, Jan 15, 2021 at 18:15 Greg Ewing wrote: > On 16/01/21 2:09 pm, Guido van Rossum wrote: > > Yeah, that wasn't very clear, and I'm not 100% sure I got it right. But > > consider this: > > ``` > > class Outer: > > foo = 1 > > class Inner: > > print(foo) > > That's true.

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

On 16/01/21 2:09 pm, Guido van Rossum wrote: Yeah, that wasn't very clear, and I'm not 100% sure I got it right. But consider this: ``` class Outer:     foo = 1     class Inner:     print(foo) That's true. So maybe the user should have to be explicit in cases like this: class Outer:

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

On Fri, Jan 15, 2021 at 4:45 PM Greg Ewing wrote: > On 16/01/21 9:38 am, Guido van Rossum wrote: > > On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings > > wrote: > > > > class OuterCls: > > class InnerCls: > > def

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

On 16/01/21 9:38 am, Guido van Rossum wrote: On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings > wrote: class OuterCls:     class InnerCls:         def method(a:OuterCls.InnerCls=None): pass We've turned the local reference into a global

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

On 1/15/21 3:29 PM, Greg Ewing wrote: On 16/01/21 7:56 am, Larry Hastings wrote: As mentioned previously in this thread, typing.get_type_hints() is opinionated in ways that users of annotations may not want. This brings us back to my idea of introducing a new annotations() function to hide

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

Would annotations() just access the dunder, like other builtins (and then result in the descriptor resolving __co_annotations__ as proposed), or would calling it be required to actually resolve __co_annotations__? I think it should probably be the former. On Sat, 2021-01-16 at 12:29 +1300, Greg

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

On 16/01/21 7:56 am, Larry Hastings wrote: As mentioned previously in this thread, typing.get_type_hints() is opinionated in ways that users of annotations may not want. This brings us back to my idea of introducing a new annotations() function to hide the details. It wouldn't be the same

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

I knew I was missing something. Agree, annotations are not necessarily type hints. On Fri, 2021-01-15 at 10:56 -0800, Larry Hastings wrote: > > On 1/15/21 10:12 AM, Paul Bryan wrote: > > > I wonder if then the __co_annotations__ call and overwriting of > > __annotations__ should be explicitly

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

On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings wrote: > > Sorry it took me 3+ days to reply--I had a lot to think about here. But I > have good things to report! > > > On 1/11/21 8:42 PM, Guido van Rossum wrote: > > On Mon, Jan 11, 2021 at 1:20 PM Larry Hastings wrote: > >> PEP 563 states: >>

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

On 1/15/21 10:12 AM, Paul Bryan wrote: I wonder if then the __co_annotations__ call and overwriting of __annotations__ should be explicitly caused by a to get_type_hints instead of (mysteriously) occurring on an attempt to getattr __annotations__. I would say: absolutely not.  While all

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

Sorry it took me 3+ days to reply--I had a lot to think about here.  But I have good things to report! On 1/11/21 8:42 PM, Guido van Rossum wrote: On Mon, Jan 11, 2021 at 1:20 PM Larry Hastings > wrote: PEP 563 states: For code that uses type hints,

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

OK. Makes sense to think of __annotations__ as being the location of the final, stable, "affixed" type hints. I wonder if then the __co_annotations__ call and overwriting of __annotations__ should be explicitly caused by a to get_type_hints instead of (mysteriously) occurring on an attempt to

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2021-01-08 - 2021-01-15) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7546 ( -3) closed 47126 (+71) total 54672 (+68) Open issues

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

On 1/11/21 6:34 PM, Paul Bryan wrote: On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote: On 1/11/21 5:02 PM, Paul Bryan wrote: I'm probably naive, but is there a reason that one could not just store a callable in __annotations__, and use the descriptor to resolve it to a dictionary

[Python-Dev] Re: Unification of the Mac builds?

> On 14 Jan 2021, at 23:03, Chris Barker via Python-Dev > wrote: > > Ned, > > Thanks -- I'll take further discussion to the python-mac list. > > Ronald: > > That’s a feature of the framework build. The unix build is exactly the same > as a unix build on other platform. Adding the same

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

On Fri, Jan 15, 2021 at 08:24:54AM +, Julien Palard via Python-Dev wrote: > I think the best way to handle this is to make the three next releases > (3.10, 3.11, 3.12) Sphinx 2 and Sphinx 3 compatible, this would gather > requiered benefits: > > If this plan is OK for everyone, I'll try a

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

> Then the correct endpoint would more likely to be PyObject_New(), but > there's no way to intercept such calls for statistical analysis > currently. And as you wrote, if some code decide to use PyMalloc() > directly, then that memory won't be tracked. The one that CPython uses in debug mode to

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

On Fri, Jan 15 2021, Pablo Galindo Salgado wrote: >> Exactly, which is a bit a bummer. Considering Python provides 3 >> different memory allocator, it'd be great if there was some ability to >> be sure that PyObject_Malloc pointer are actually PyObject, not >> Py_GC_HEAD. > > The allocators are

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

Le 15/01/2021 à 13:08, Julien Danjou a écrit : > On Fri, Jan 15 2021, Antoine Pitrou wrote: > >> Also note that PyObject_Malloc() may also be used to allocate >> non-objects, for example a bytearray's payload, IIRC. > > Interesting. What's the rational for not using PyMem_Malloc() in such >

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

On Fri, Jan 15 2021, Antoine Pitrou wrote: > Also note that PyObject_Malloc() may also be used to allocate > non-objects, for example a bytearray's payload, IIRC. Interesting. What's the rational for not using PyMem_Malloc() in such cases? -- Julien Danjou # Free Software hacker #

[Python-Dev] Re: 3.10 change (?) for __bool__

On Fri, Jan 15, 2021 at 10:13 PM Rob Cliffe via Python-Dev wrote: > > > > On 12/01/2021 15:53, Mark Shannon wrote: > > Hi everyone, > > > > > > > > In master we convert `if x: pass` to `pass` which is equivalent, > > unless bool(x) has side effects the first time it is called. This is a > >

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

> Exactly, which is a bit a bummer. Considering Python provides 3 > different memory allocator, it'd be great if there was some ability to > be sure that PyObject_Malloc pointer are actually PyObject, not > Py_GC_HEAD. The allocators are specialized based on the allocation strategy and

[Python-Dev] Re: 3.10 change (?) for __bool__

On 12/01/2021 15:53, Mark Shannon wrote: Hi everyone, In master we convert `if x: pass` to `pass` which is equivalent, unless bool(x) has side effects the first time it is called. This is a recent change. Suppose x is not a currently valid variable name at runtime.  Will the NameError

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

On Fri, 15 Jan 2021 09:36:11 +0100 Julien Danjou wrote: > On Thu, Jan 14 2021, Tim Peters wrote: > > > I'm not clear on exactly what it is you're after, but CPython faces > > the same question all the time: _given_ a pointer to an object, is > > there, or is there not, a GC header prepended?

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

On Thu, Jan 14 2021, Tim Peters wrote: > I'm not clear on exactly what it is you're after, but CPython faces > the same question all the time: _given_ a pointer to an object, is > there, or is there not, a GC header prepended? That's answered by > this C API function: > > """ > int

[Python-Dev] Re: PyGC and PyObject_Malloc introspection

On Thu, Jan 14 2021, Pablo Galindo Salgado wrote: Hi Pablo, > Isn't this a similar problem that you have with regular malloc? When you > call malloc() with > some size, malloc actually will reserve more than that for > alignment purposes and for > bookkeeping and apart from some

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

Thanks everyone for the feedback. I think the best way to handle this is to make the three next releases (3.10, 3.11, 3.12) Sphinx 2 and Sphinx 3 compatible, this would gather requiered benefits: - Ease of backporting: from any dev version we can backport documentation changes to the previous