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

2021-01-15 Thread Julien Palard via Python-Dev
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 two releases.
- Ease of packaging: We're not requiering Sphinx 3 today but in like 3 
years, a point where this could be discussed again to see if everyone is 
ready.

If this plan is OK for everyone, I'll try a PR soon™ to make this 
compatibility with Sphinx2/3 land in 3.10.

-- 
[Julien Palard](https://mdk.fr)
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/VQ5IZPQWJXVXRWCOS5S3Z7DH7YJCONJT/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Julien Danjou
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 platform-specific APIs
> like malloc_usable_size()
> you cannot query that value.

Not really. It's not a real problem if malloc reserve more memory than
the size you requested if you still know the original size.
When working with Python memory allocator API, you do have this original
size so you're able to read the memory from its beginning (the allocated
pointer address) to its end.

> My answer would be that that's because memory itself cannot be gc tracked,
> only objects can and those belonging to different
> categories. For example, notice that the tracemalloc module does not report
> objects, it only reports memory blocks and you
> cannot ask tracemalloc to give you a list of all the objects that were
> allocated because it does not have the notion of what
> an object is.

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.

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/MMCIEUV62ER6DWYG7FVIRCRD2KI3E4EZ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Julien Danjou
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 PyObject_IS_GC(PyObject *obj)
>
> Returns non-zero if the object implements the garbage collector
> protocol, otherwise returns 0.
>
> The object cannot be tracked by the garbage collector if this function
> returns 0.
> """
>
> FYI, the implementation usually resolves it by looking at whether
> obj's type object has the Py_TPFLAGS_HAVE_GC flag set.

Right, but that only works if you have the PyObject address.
If you all got is a pointer returned by PyObject_Malloc(), you don't
know if the PyObject is at this pointer address, or after the PyGC_HEAD
header that is prepended. :(

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/Z6GJUNKOFE2IN6EKQKDBBMX4SUZ36ITU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Antoine Pitrou
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?  That's answered by
> > this C API function:
> >
> > """
> > int PyObject_IS_GC(PyObject *obj)
> >
> > Returns non-zero if the object implements the garbage collector
> > protocol, otherwise returns 0.
> >
> > The object cannot be tracked by the garbage collector if this function
> > returns 0.
> > """
> >
> > FYI, the implementation usually resolves it by looking at whether
> > obj's type object has the Py_TPFLAGS_HAVE_GC flag set.  
> 
> Right, but that only works if you have the PyObject address.
> If you all got is a pointer returned by PyObject_Malloc(), you don't
> know if the PyObject is at this pointer address, or after the PyGC_HEAD
> header that is prepended. :(

Also note that PyObject_Malloc() may also be used to allocate
non-objects, for example a bytearray's payload, IIRC.

Regards

Antoine.

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/DCXBZ6UJ5OKYCUL6MSWVQD6JT7YW5QON/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Rob Cliffe via Python-Dev



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 still be "optimised" away?

Thanks
Rob Cliffe
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/JK4QENGPZV56RNGI5YHLWCL4OF4AEGSP/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Pablo Galindo Salgado
> 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 efficiency, not based on what are you going to use the memory
for. If you want to allocate a buffer using the object allocation
strategy because  then nobody is preventing you
to use PyObject_Malloc(). Even if we sanitize the whole stdlib to
be conforming to "only objects are allocated using PyObejct_Malloc()",
3rd party extension modules and other bests can do whatever, so you
can still crash if you decide to interpreter the output as an object.


On Fri, 15 Jan 2021 at 08:43, 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?  That's answered by
> > this C API function:
> >
> > """
> > int PyObject_IS_GC(PyObject *obj)
> >
> > Returns non-zero if the object implements the garbage collector
> > protocol, otherwise returns 0.
> >
> > The object cannot be tracked by the garbage collector if this function
> > returns 0.
> > """
> >
> > FYI, the implementation usually resolves it by looking at whether
> > obj's type object has the Py_TPFLAGS_HAVE_GC flag set.
>
> Right, but that only works if you have the PyObject address.
> If you all got is a pointer returned by PyObject_Malloc(), you don't
> know if the PyObject is at this pointer address, or after the PyGC_HEAD
> header that is prepended. :(
>
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */
> ___
> 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
> https://mail.python.org/archives/list/python-dev@python.org/message/Z6GJUNKOFE2IN6EKQKDBBMX4SUZ36ITU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/KIBIVCKSXVE77YE3PWPPK7QPBAFQFMOU/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Chris Angelico
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
> > recent change.
> >
> Suppose x is not a currently valid variable name at runtime.  Will the
> NameError still be "optimised" away?

No, it won't. The expression still gets fully evaluated. The ONLY part
that gets optimized away is the check "is this thing true?".

ChrisA
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/KQ2QH3VB5Q6LYCBE4SUWZKRMML54TOXS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Julien Danjou
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
# https://julien.danjou.info
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/6GM4IOWIQWAQNBRAAPZBC5TRD2HZ7VTL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Antoine Pitrou

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
> cases?

I think PyMem_Malloc() just redirects to PyObject_Malloc() nowadays.
Historically though, PyMem_Malloc() was a thin wrapper around the system
malloc(), and it could therefore be slower than PyObject_Malloc() for
small payloads.

Regards

Antoine.
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/6OH6N6YAGL6MRFJVOGLV3UYY5JCDRQKN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Julien Danjou
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 specialized based on the allocation strategy
> and efficiency, not based on what are you going to use the memory
> for. If you want to allocate a buffer using the object allocation
> strategy because  then nobody is preventing you
> to use PyObject_Malloc(). Even if we sanitize the whole stdlib to
> be conforming to "only objects are allocated using PyObejct_Malloc()",
> 3rd party extension modules and other bests can do whatever, so you
> can still crash if you decide to interpreter the output as an object.

Agreed.

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.

It sounds like the provided C API is a bit too low level for this,
preventing any kind of statistical analysis of the allocation patterns.
:(

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/UAWA2ADOQNI5IAGI3YVNE7EYKGSBIHZ5/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PyGC and PyObject_Malloc introspection

2021-01-15 Thread Pablo Galindo Salgado
> 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 track all references for
sys.getobjects() is PyObject_Init(), which is heavily inlined for
performance
reasons (the same as many of the other calls in the allocation chain), so
unfortunately
is not possible to intercept using LD_PRELOAD or even GOT patching.

> t sounds like the provided C API is a bit too low level for this,
> preventing any kind of statistical analysis of the allocation patterns.
> :(

Yes, allowing interception or customization will prevent inlining or other
optimizations
and therefore will involve a considerable performance hit. As an experiment
I forced
PyObject_Init and _PyObject_Init to not be inlined and that made a 7-13%
speed
impact overall in the performance test suite.

If you want to track all objects creation, your best bet IMHO is a debug
build and to use sys.getobjects().

Regards from sunny London,
Pablo Galindo Salgado


On Fri, 15 Jan 2021 at 12:17, Julien Danjou  wrote:

> 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 specialized based on the allocation strategy
> > and efficiency, not based on what are you going to use the memory
> > for. If you want to allocate a buffer using the object allocation
> > strategy because  then nobody is preventing you
> > to use PyObject_Malloc(). Even if we sanitize the whole stdlib to
> > be conforming to "only objects are allocated using PyObejct_Malloc()",
> > 3rd party extension modules and other bests can do whatever, so you
> > can still crash if you decide to interpreter the output as an object.
>
> Agreed.
>
> 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.
>
> It sounds like the provided C API is a bit too low level for this,
> preventing any kind of statistical analysis of the allocation patterns.
> :(
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/A6FCIFGSWL6POYZNIEYPZVCQMJDOES7P/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Senthil Kumaran
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 PR soon™ to make this 
> compatibility with Sphinx2/3 land in 3.10.
> 

This sounds great. It makes one less thing to worry about from a CPython
developer perspective.

--
Senthil
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/SATCMWFM7WKW7A2V2TXR4ICX52ZZ6DRG/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Ronald Oussoren via Python-Dev


> 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 feature to the unix build 
> should be possible, but would complicate the build.  I have no interest to 
> work on this, but would be willing to review PRs,
> 
> fair enough.
>  
> as long as those aim for feature parity with the framework build. That is, 
> both pythonw(1) and python(1) should redirect through an embedded app bundle.
> 
> yes, that's what I'm thinking.
> 
> Done, just configure “—enable-universalsdk —with-universal-archs=universal2” 
> without specifying a framework build.
> 
> Excellent, thanks!
> 
> Something I would like to work on, but don’t have enough free time for, is an 
> alternative installation with an application bundle on the top level instead 
> of a framework.  Installation would then entail dropping “Python X.Y.app” 
> into your application folder, and uninstallation would be to drop the same 
> bundle into the bin.
> 
> That would be nice -- and would, I think, actually buy us something useful 
> from this bundling :-)

To be honest I’d expect that this will also lead to complaining about how this 
build is not a unix build ;-) 

> 
> Just don’t use conda ;-).  To be blunt, doing this properly is trivial.
> 
> which "this" are you referring to -- and if it's trivial, then why hasn't 
> anyone figured out how in multiple conversations over years?
“This” is having a pythonw that’s the same as in framework builds.

I don’t know. I do know that nobody asked questions about this before.

> 
> But if it is -- tell us how and maybe we will do it (if it's really trivial, 
> maybe even I, with my limited build skills could do it)


For anyone reading along that isn’t familiar with macOS: On macOS a number of 
system libraries, and in particular GUI libraries, require that they are used 
from an application bundle (‘.app”).   For Python we want to be able to just 
use the command-line for simple scripts (and testing of more complicated 
applications), instead having to build an app bundle every time.

In framework builds this is solved by two changes relative to a unix build:
1. The regular python binary is in 
“{sys.prefix}/Resources/Python.app/Contents/MacOS/Python”
2. “{sys.executable}” (or “{sys.prefix}/bin/python3”) is a stub executable that 
does nothing but execv[1] the regular python binary. The source of this binary 
is in Mac/Tools/pythonw.c


Note: All of this requires using a shared library build (—enable-shared) 
because of the way the stub finds sys.prefix.

To add this to the unix build as well requires:
1. Make up a location for the Python.app
2. Change the Makefile(.pre.in) to build the stub executable install files in 
their new location, but only when installing on macOS with an —enable-shared 
build
3. Tweak the code in pythonw.c to calculate the correct path to Python.app 
4. Possibly tweak the calculation of sys.prefix for unix builds, IIRC the 
special macOS sauce is enabled for framework builds only
5. Do some debugging because this list is likely incomplete, I typed it from 
memory


Ronald

[1] for the pedantically correct: it actually uses posix_spawn in exec mode to 
ensure that the correct CPU architecture is used. That’s why “arch -x86_64 
python3.9” works when you use the universal2 installer for python 3.9, if we’d 
use execv the stub would launch the actual interpreter in native mode.

Ronald

> 
> Thanks,
> 
> -CHB
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
> 
> chris.bar...@noaa.gov 
> ___
> 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 
> https://mail.python.org/archives/list/python-dev@python.org/message/7YZ4JB5PTL2LKGRCNZF7X4TP7ZYTBW3H/
> Code of Conduct: http://python.org/psf/codeofconduct/

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/AYVB5ILUE4B4XNVNDSZ2LUJ2SHT3IS6W/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Larry Hastings


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 and store it when it is accessed? It 
would be one less dunder in the Python data model.


That would work, but I think the API is a bit of a code smell.  
__annotations__ would no longer be stable:



a.__annotations__ = o
assert a.__annotations__ == o

Would that assert fail?  It depends on what type(o) is, which is 
surprising.




Equally surprising?:

a.__co_annotations__ = o
a.__annotations__
assert a.__co_annotations__ == o



I've ruminated about this a bit over the past few days, and I finally 
realized exactly why, yes, I think behavior is more surprising.  It's 
because __annotations__ is now 12 years old (!), and never in that 
entire time has it silently changed its value. It's always been 
completely stable, and we have twelve years' worth of installed base 
that may rely on that assumption.  In comparison, __co_annotations__ is 
a new attribute.  While it's also surprising that __co_annotations__ can 
be automatically unset, at least this would be a documented part of its 
behavior from day 1.


Relatedly, __co_annotations__ is behaving somewhat like a cached value, 
in that cached values get deleted when they're out-of-date.  (An 
observation that may provide some guidance if we decide to rename 
__co_annotations__.)  This idiom may be familiar to the user--unlike 
your proposed semantics, which I don't recall ever seeing used in an API.


I admit it's only a small difference between what you proposed and what 
I propose, but in the end I definitely prefer my approach.


Cheers,


//arry/

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/HVIVCQ6AONKRZYWNY4VYHAOWT3WTEJAF/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Summary of Python tracker Issues

2021-01-15 Thread Python tracker

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 with patches: 3027 


Issues opened (41)
==

#41837: Upgrade installers to OpenSSL 1.1.1i
https://bugs.python.org/issue41837  reopened by christian.heimes

#42869: pydoc does not append .html to documentation
https://bugs.python.org/issue42869  opened by mdk

#42871: Regex compilation crashed if I change order of alternatives un
https://bugs.python.org/issue42871  opened by Renji

#42872: Inconsistent exceptions thrown by pathlib.Path.mkdir on differ
https://bugs.python.org/issue42872  opened by Hong Xu

#42874: running configure on Solaris 10 gives grep "illegal option" er
https://bugs.python.org/issue42874  opened by martin.wheatley.home

#42875: argparse incorrectly shows help string on a new line in case o
https://bugs.python.org/issue42875  opened by DiPaolo

#42878: urllib.request.HTTPPasswordMgr.is_suburi does not care about o
https://bugs.python.org/issue42878  opened by Fongeme

#42880: ctypes: variadic function call still doesn't work on Apple Sil
https://bugs.python.org/issue42880  opened by lazymio

#42881: Should typing.get_type_hints change None annotations?
https://bugs.python.org/issue42881  opened by larry

#42884: array.index() missing start and end
https://bugs.python.org/issue42884  opened by daniel.nicorici

#42885: Regex performance problem with ^ aka AT_BEGINNING
https://bugs.python.org/issue42885  opened by 2d4d

#42887: Multiple assignments of attribute "__sizeof__" will cause a se
https://bugs.python.org/issue42887  opened by xxm

#42888: Not installed “libgcc_s.so.1” causes parser crash.
https://bugs.python.org/issue42888  opened by xxm

#42889: Incorrect behavior of Python parser after ast node of test pro
https://bugs.python.org/issue42889  opened by xxm

#42892: AttributeError in email.message.get_body()
https://bugs.python.org/issue42892  opened by xavier2

#42893: Strange XPath search behavior of xml.etree.ElementTree.Element
https://bugs.python.org/issue42893  opened by robpats

#42894: Debugging native Python modules on Windows with Visual Studio 
https://bugs.python.org/issue42894  opened by jmoguill2

#42896: Solaris 11.4 crle output not handled correctly
https://bugs.python.org/issue42896  opened by dmurphy18

#42897: Expose a way to determine if a process has been closed or not
https://bugs.python.org/issue42897  opened by petervansickel

#42899: Is it legal to eliminate tests of a value, when that test has 
https://bugs.python.org/issue42899  opened by stestagg

#42901: [Enum] move member creation to __set_name__ in order to suppor
https://bugs.python.org/issue42901  opened by ethan.furman

#42902: a python embedded program may load "C:\Lib\os.py" on windows 
https://bugs.python.org/issue42902  opened by houjingyi233

#42904: get_type_hints does not provide localns for classes
https://bugs.python.org/issue42904  opened by pbryan

#42909: Email header with  stuffing takes very long to parse
https://bugs.python.org/issue42909  opened by eriker

#42911: Addition chains for pow saves 5-20% time for pow(int,int)
https://bugs.python.org/issue42911  opened by jneb

#42913: asyncio.ProactorEventLoop mishandles signal wakeup file descri
https://bugs.python.org/issue42913  opened by hidmic

#42914: pprint numbers with underscore
https://bugs.python.org/issue42914  opened by fov

#42915: enum.Flag ~ bitwise negation is very slow and can't be defined
https://bugs.python.org/issue42915  opened by aspin2

#42916: Support for DICOM image file format in imghdr module
https://bugs.python.org/issue42916  opened by claw

#42917: Block stack size for frame objects should be dynamically sizab
https://bugs.python.org/issue42917  opened by tomkpz

#42918: Nested multi-line expression will lead to "compile()" fails
https://bugs.python.org/issue42918  opened by xxm

#42919: Blank in multiline “if expressions” will lead to EOF error
https://bugs.python.org/issue42919  opened by xxm

#42921: Inferred Optional type of wrapper function arguments
https://bugs.python.org/issue42921  opened by joperez

#42923: Py_FatalError(): dump the list of extension modules
https://bugs.python.org/issue42923  opened by vstinner

#42924: bytearray_repeat copies from ob_bytes instead of ob_start
https://bugs.python.org/issue42924  opened by tholl

#42925: Error trace of else inside class
https://bugs.python.org/issue42925  opened by ChenXuan

#42926: Split compiler into code-gen, optimizer and assembler.
https://bugs.python.org/issue42926  opened by Mark.Shannon

#42927: Inline cache for slots
https://bugs.python.org/issue42927  opened by gvanrossum

#42929: On Windows, shutil.move doesn't raise FileExistsError if dst e
https://bugs.python.org/issue42929  opened by fireattack

#42931: Include r

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

2021-01-15 Thread Paul Bryan via Python-Dev
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 getattr
__annotations__. I know this changes the descriptor behavior you
documented, but at least it would occur explicitly in a function call
and may be easier for developers to reason about?  It would also
address my other question of trying to access __annotations__, only to
be confronted with an exception raised within __co_annotations__.


On Fri, 2021-01-15 at 09:47 -0800, Larry Hastings wrote:
> 
> 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 and store it when it is accessed? It
> > > would be one less dunder in the Python data model.
> > That would work, but I think the API is a bit of a code smell. 
> > __annotations__ would no longer be stable:
> > 
> > > a.__annotations__ = o
> > > assert a.__annotations__ == o
> > Would that assert fail?  It depends on what type(o) is, which is
> > surprising.
> 
> Equally surprising?:
> 
> a.__co_annotations__ = o
> a.__annotations__
> assert a.__co_annotations__ == o
> 
> I've ruminated about this a bit over the past few days, and I finally
> realized exactly why, yes, I think behavior is more surprising.  It's
> because __annotations__ is now 12 years old (!), and never in that
> entire time has it silently changed its value.  It's always been
> completely stable, and we have twelve years' worth of installed base
> that may rely on that assumption.  In comparison, __co_annotations__
> is a new attribute.  While it's also surprising that
> __co_annotations__ can be automatically unset, at least this would be
> a documented part of its behavior from day 1.
> Relatedly, __co_annotations__ is behaving somewhat like a cached
> value, in that cached values get deleted when they're out-of-date. 
> (An observation that may provide some guidance if we decide to rename
> __co_annotations__.)  This idiom may be familiar to the user--unlike
> your proposed semantics, which I don't recall ever seeing used in an
> API.
> I admit it's only a small difference between what you proposed and
> what I propose, but in the end I definitely prefer my approach.
> Cheers,
> 
> /arry

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/AV6JRZZDDN4GAPE5MHRFEBFUY3TEO7VZ/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Larry Hastings


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, the typing.get_type_hints(obj,
globalns=None, localns=None) function correctly evaluates
expressions back from its string form.

So, if you are passing in a localns argument that isn't None,
okay, but you're not using them "correctly" according to the
language.  Also, this usage won't be compatible with static type
checkers.

I think you're misreading PEP 563 here. The mention of globalns=None, 
localns=None refers to the fact that these parameters have defaults, 
not that you must pass None. Note that the next paragraph in that PEP 
mentions eval(ann, globals, locals) -- it doesn't say eval(ann, {}, {}).


I think that's misleading, then.  The passage is telling you how to 
"correctly evaluate[s] expressions", and how I read it was, it's telling 
me I have to supply globalns=None and localns=None for it to work 
correctly--which, I had to discover on my own, were the default values.  
I don't understand why PEP 563 feels compelled to define a function that 
it's not introducing, and in fact had already shipped with Python two 
versions ago.



Later in that same section, PEP 563 points out a problem with 
annotations that reference class-scoped variables, and claims that the 
implementation would run into problems because methods can't "see" the 
class scope. This is indeed a problem for PEP 563, but *you* can 
easily generate correct code, assuming the containing class exists in 
the global scope (and your solution requires that anyway). So in this case

```
class Outer:
    class Inner:
   ...
    def method(self, a: Inner, b: Outer) -> None:
    ...
```
The generated code for the `__annotations__` property could just have 
a reference to `Outer.Inner` for such cases:

```
def __annotations__():
    return {"a": Outer.Inner, "b": Outer, "return": None}
```


This suggestion was a revelation for me.  Previously, a combination of 
bad experiences early on when hacking on compile and symtable, and my 
misunderstanding of exactly what was being asserted in the November 2017 
thread, led me to believe that all I could support was globals.  But 
I've been turning this over in my head for several days now, and I 
suspect I can support... just about anything.



I can name five name resolution scenarios I might encounter. I'll 
discuss them below, in increasing order of difficulty.



*First* is references to globals / builtins.  That's already working, 
it's obvious how it works, and I need not elaborate further.



*Second* is local variables in an enclosing function scope:

   def outer_fn():
    class C: pass
    def inner_fn(a:C=None): pass
    return inner_fn

As you pointed out elsewhere in un-quoted text, I could make the 
annotation a closure, so it could retain a reference to the value of 
(what is from its perspective) the free variable "C".



*Third* is local variables in an enclosing class scope, as you describe 
above:


   class OuterCls:
    class InnerCls:
        def method(a:InnerCls=None): pass

If I understand what you're suggesting, I could notice inside the 
compiler that Inner is being defined in a class scope, walk up the 
enclosing scopes until I hit the outermost class, then reconstruct the 
chain of pulling out attributes until it resolves globally. Thus I'd 
rewrite this example to:


   class OuterCls:
    class InnerCls:
        def method(a:OuterCls.InnerCls=None): pass

We've turned the local reference into a global reference, and we already 
know globals work fine.



*Fourth* is local variables in an enclosing class scope, which are 
themselves local variables in an enclosing function scope:


   def outerfn():
    class OuterCls:
    class InnerCls:
        def method(a:InnerCls=None): pass
    return OuterCls.InnerCls

Even this is solvable, I just need to combine the "second" and "third" 
approaches above.  I walk up the enclosing scopes to find the outermost 
class scope, and if that's a function scope, I create a closure and 
retain a reference to /that/ free variable.  Thus this would turn into


   def outerfn():
    class OuterCls:
    class InnerCls:
        def method(a:OuterCls.InnerCls=None): pass

and method.__co_annotations__ would reference the free variable 
"OuterCls" defined in outerfn.



*Fifth* is the nasty one.  Note that so far every definition we've 
referred to in an annotation has been /before/ the definition of the 
annotation.  What if we want to refer to something defined /after/ the 
annotation?


   def outerfn():
    class OuterCls:
    class InnerCls:
        def method(a:zebra=None): pass
    ...

We haven't 

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

2021-01-15 Thread Larry Hastings


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 "type hints" are annotations, 
not all annotations are "type hints".  As mentioned previously in this 
thread, typing.get_type_hints() is opinionated in ways that users of 
annotations may not want.  And personally I bristle at the idea of 
gating a language feature behind a library function.


Besides, most users will never know or care about __co_annotations__.  
If you're not even aware that it exists, it's not mysterious ;-)



Cheers,


//arry/

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/JOBGFRXKFBB5TYEVGJZ7INEAEC4ZQDBY/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Guido van Rossum
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:
>>
>> For code that uses type hints, the typing.get_type_hints(obj,
>> globalns=None, localns=None) function correctly evaluates expressions back
>> from its string form.
>>
>> So, if you are passing in a localns argument that isn't None, okay, but
>> you're not using them "correctly" according to the language.  Also, this
>> usage won't be compatible with static type checkers.
>>
> I think you're misreading PEP 563 here. The mention of globalns=None,
> localns=None refers to the fact that these parameters have defaults, not
> that you must pass None. Note that the next paragraph in that PEP mentions
> eval(ann, globals, locals) -- it doesn't say eval(ann, {}, {}).
>
> I think that's misleading, then.  The passage is telling you how to
> "correctly evaluate[s] expressions", and how I read it was, it's telling me
> I have to supply globalns=None and localns=None for it to work
> correctly--which, I had to discover on my own, were the default values.  I
> don't understand why PEP 563 feels compelled to define a function that it's
> not introducing, and in fact had already shipped with Python two versions
> ago.
>

I suppose PEP 563 is ambiguous because on the one hand global symbols are
the only things that work out of the box, on the other hand you can make
other things work by passing the right scope (and there's lots of code now
that does so), and on the third hand, it claims that get_type_hints() adds
the class scope, which nobody noticed or implemented until this week
(there's a PR, can't recall the number).

But I think all this is irrelevant given what comes below.

>
> Later in that same section, PEP 563 points out a problem with annotations
> that reference class-scoped variables, and claims that the implementation
> would run into problems because methods can't "see" the class scope. This
> is indeed a problem for PEP 563, but *you* can easily generate correct
> code, assuming the containing class exists in the global scope (and your
> solution requires that anyway). So in this case
> ```
> class Outer:
> class Inner:
>...
> def method(self, a: Inner, b: Outer) -> None:
> ...
> ```
> The generated code for the `__annotations__` property could just have a
> reference to `Outer.Inner` for such cases:
> ```
> def __annotations__():
> return {"a": Outer.Inner, "b": Outer, "return": None}
> ```
>
> This suggestion was a revelation for me.  Previously, a combination of bad
> experiences early on when hacking on compile and symtable, and my
> misunderstanding of exactly what was being asserted in the November 2017
> thread, led me to believe that all I could support was globals.  But I've
> been turning this over in my head for several days now, and I suspect I can
> support... just about anything.
>
>
> I can name five name resolution scenarios I might encounter.  I'll discuss
> them below, in increasing order of difficulty.
>
>
> *First* is references to globals / builtins.  That's already working,
> it's obvious how it works, and I need not elaborate further.
>

Yup.

>
> *Second* is local variables in an enclosing function scope:
>
> def outer_fn():
> class C: pass
> def inner_fn(a:C=None): pass
> return inner_fn
>
> As you pointed out elsewhere in un-quoted text, I could make the
> annotation a closure, so it could retain a reference to the value of (what
> is from its perspective) the free variable "C".
>

Yup.

>
> *Third* is local variables in an enclosing class scope, as you describe
> above:
>
> class OuterCls:
> class InnerCls:
> def method(a:InnerCls=None): pass
>
> If I understand what you're suggesting, I could notice inside the compiler
> that Inner is being defined in a class scope, walk up the enclosing scopes
> until I hit the outermost class, then reconstruct the chain of pulling out
> attributes until it resolves globally.  Thus I'd rewrite this example to:
>
> class OuterCls:
> class InnerCls:
> def method(a:OuterCls.InnerCls=None): pass
>
> We've turned the local reference into a global reference, and we already
> know globals work fine.
>

I think this is going too far. A static method defined in InnerCls does not
see InnerCls (even after the class definitions are complete). E.g.
```
class Outer:
class Inner:
@staticmethod
def foo(): return Inner
```
If you then call Outer.Inner.foo() you get "NameError: name 'Inner' is not
defined".


>
> *Fourth* is local variables in an enclosing class scope, which are
> themselves local variables in an enclosing function scope:
>
> def outerfn():
> class OuterCls:
> class InnerCls:
> def method(a:InnerCls=None): pass
> return OuterCls.InnerCls
>

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

2021-01-15 Thread Paul Bryan via Python-Dev
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 caused by a to get_type_hints
> > instead of (mysteriously) occurring on an attempt to getattr
> > __annotations__.
> 
> I would say: absolutely not.  While all "type hints" are annotations,
> not all annotations are "type hints".  As mentioned previously in
> this thread, typing.get_type_hints() is opinionated in ways that
> users of annotations may not want.  And personally I bristle at the
> idea of gating a language feature behind a library function.
> Besides, most users will never know or care about
> __co_annotations__.  If you're not even aware that it exists, it's
> not mysterious ;-)
> 
> Cheers,
> 
> /arry

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/C3HINI65UIFCA4EON55WMR6YR6THXQCQ/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Greg Ewing

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 as get_type_hints(), since it wouldn't make
any assumptions about what the annotations mean.

--
Greg
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/OHMQLQXGJDZLYTACJBGZIPJV45H2LF5H/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Paul Bryan via Python-Dev
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 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 the details. It wouldn't
> be the same as get_type_hints(), since it wouldn't make
> any assumptions about what the annotations mean.
> 

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/457EYGAJAE4BQHUWH32MRZNSLFGNR6MM/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Larry Hastings


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 the details. It wouldn't
be the same as get_type_hints(), since it wouldn't make
any assumptions about what the annotations mean.



I think it's simpler and nicer for the user to preserve the existing 
interface, so I'm sticking with that approach.  If you feel strongly 
about this, I encourage you to write your own competing PEP.



//arry/

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/ZRFIAWZ772NOWAY4VE4WBNFPHNLIMX5V/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Greg Ewing

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 reference, and we
already know globals work fine.


I think this is going too far. A static method defined in InnerCls does 
not see InnerCls (even after the class definitions are complete). E.g.

```
class Outer:
     class Inner:
         @staticmethod
         def foo(): return Inner
```
If you then call Outer.Inner.foo() you get "NameError: name 'Inner' is 
not defined".


I'm not so sure about that. Conceptually, annotations are evaluated
in the environment existing when the class scope is being constructed.
The fact that we're moving them into a closure is an implementation
detail that I don't think should be exposed.


What if we want to refer to something defined /after/
the annotation?

def outerfn():
     class OuterCls:
     class InnerCls:
         def method(a:zebra=None): pass
     ...

We haven't seen the definition of "zebra" yet, so we don't know what
approach to take.


I don't think that should be a problem. The compiler already knows
about all the assignments occurring in a scope before starting to
generate code for it.

--
Greg
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/SX66DYOEZSQCLY6JJMIDBS4LFHPB76Y3/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Guido van Rossum
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 method(a:OuterCls.InnerCls=None): pass
> >
> > We've turned the local reference into a global reference, and we
> > already know globals work fine.
>
> [Above was what Larry wrote, the rest is me. I guess Greg's mailer is
having trouble with the GMail-style quoting. :-( ]

> I think this is going too far. A static method defined in InnerCls does
> > not see InnerCls (even after the class definitions are complete). E.g.
> > ```
> > class Outer:
> >  class Inner:
> >  @staticmethod
> >  def foo(): return Inner
> > ```
> > If you then call Outer.Inner.foo() you get "NameError: name 'Inner' is
> > not defined".
>

[Greg]

> I'm not so sure about that. Conceptually, annotations are evaluated
> in the environment existing when the class scope is being constructed.
> The fact that we're moving them into a closure is an implementation
> detail that I don't think should be exposed.
>

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)
```
This gives "NameError: name 'foo' is not defined". And here there is no
forward reference involved, and foo lives in the exactly the same
scope/namespace as Inner.

The reason for the NameError is that class scopes don't participate in the
closure game (an intentional design quirk to avoid methods referencing
unqualified class variables).

So I still think that Larry's example shouldn't (have to) work.

(I agree with Greg on the 'zebra' example.)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/5HSBXTJB5GIXAW7NPRA7DNJSBSJH3BRP/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Greg Ewing

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:
class Inner:
  def f(x: Outer.Inner): ...

However, I think cases like this should work:

  class C:
t = List[int]
def f(x: t): ...

even though the closure placed in C.__co_annotations__ wouldn't
normally have access to t without qualification.

--
Greg
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/YTZ3QRG3V6URZ3FDOZ6QON5DSYC52HGI/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2021-01-15 Thread Guido van Rossum
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. So maybe the user should have to be explicit in
> cases like this:
>
>class Outer:
>  class Inner:
>def f(x: Outer.Inner): ...
>
> However, I think cases like this should work:
>
>class C:
>  t = List[int]
>  def f(x: t): ...
>
> even though the closure placed in C.__co_annotations__ wouldn't
> normally have access to t without qualification.


Yes, the immediately surrounding scope should be accessible for annotations
even if it’s a class.

>
> --
--Guido (mobile)
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/Y3NLHU4GP6FBVZPGU3NDGN3S3MUEJUMD/
Code of Conduct: http://python.org/psf/codeofconduct/