[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

[Greg Ewing]

On 29/11/22 12:51 pm, Guido van Rossum wrote:
"Sets weren't meant to be deterministic" sounds like a remnant of 
the old philosophy, where we said the same about dicts -- until they 
became deterministic without slowing down, and then everybody loved it.


I got the impression that there were some internal language reasons
to want stable dicts, e.g. so that the class dict passed to __prepare__
preserves the order in which names are assigned in the class body. Are
there any such use cases for stable sets?

--
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/3TEOQMV2UXOKWMHVYA63JLPLAZ2TNX55/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Greg Ewing]

On 17/10/22 10:13 pm, Denis Kotov wrote:

For example, PyObject is much better to implement using C++ class,


I used to think this. Python has OO features, C++ has OO features,
should be a good match, right?

Well, no. Python's OO is very flexible and dynamic, C++'s is very
rigid and static. CPython uses various low-level tricks that rely
on structs being just "plain old data". The OO features of C++
wouldn't help nuch with that at all, and would often get in the
way.

If you want a Python implementation that's less prone to memory
management errors, I would suggest having a small kernel written
in C, and write the rest using a tool similar to Cython that will
take care of all the tricky reference counting for you.

--
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/7SHARSLCRFH4XOJAQOOBG4O5XVQE2CH7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

[Greg Ewing]

On 30/04/22 5:25 am, MRAB wrote:

I was going to suggest "metastable". Too late? :-)


What, the API is balanced on a knife edge and likely to collapse
into something else if you sneeze too hard?

--
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/CUWORBXDLOK74M7H6HZSXSMC5ZKMCFFY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 27/04/22 1:26 pm, Chris Angelico wrote:

On Wed, 27 Apr 2022 at 11:18, Greg Ewing  wrote:


The proposed feature is analogous to forward declaring a
struct in C. Would you call what C does monkeypatching?


No, because C doesn't have first-class types, much less mutable ones.


The purpose of a forward declaration, in any language, is to
allow a name to be used before it's fully defined. Mutability
or first-classness of types has nothing to do with it.


According to this proposal, it is entirely possible to continue a
class more than once, with just some fiddling with dunders.


No, it's not. As has been explained upthread, stuff is done
when finalising a class that can't be repeated.


But what
you're saying is that sometimes that's monkeypatching and a bad thing,
and other times it's a good thing and not monkeypatching.


No, I'm saying that the proposed feature is not monkeypatching
because it does not and cannot be used to modify an existing
class.

--
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/SVZPAEBDIGHR2TADKCOXND4S3RPKXAMY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 27/04/22 11:07 am, Chris Angelico wrote:

You're saying that it's somehow different when the original dev
intends for it, and that that makes it "not monkeypatching". I dispute
that, and I consider that the feature would be helpful whether the
original dev meant for it or not.


The forward declaration and continuation both have to be specially
marked, so you *can't* use it for monkeypatching.


Would subclassing
therefore become legitimate if the original author intended for it,
and be called "method stealing" if it were not?


You seem to think I have something against monkeypatching. Personally
I don't, but someone else seems to as they objected that they don't
want monkeypatching to be encouraged. I was just pointing out that
(1) I don't think it's the same thing as monkeypatching and (2)
you can't use it to modify an existing class in an ad-hoc manner
anyway.

--
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/6HOFAR3TKR62YFPUZ4OIBY5DJBNV374V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 27/04/22 2:01 am, Chris Angelico wrote:

That would be the case if monkeypatching were illegal. Since it's not,
wherein lies the difference?


The proposed feature is analogous to forward declaring a
struct in C. Would you call what C does monkeypatching?

--
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/5DRJG3CGCLHJSXBD6ILPHROX6LBIDCHK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 27/04/22 1:04 am, Joao S. O. Bueno wrote:

MonkeyPatching in Python is not illegal in this sense.


I'm not suggesting it is. You're seizing on the wrong part
of the analogy. The point is that what you call something
doesn't change its nature.

--
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/WFVAWIKBQF72KW2IHOERP2DIKD5ECO7N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 26/04/22 12:33 pm, Chris Angelico wrote:

That's exactly what I mean though: if the only difference between
"monkeypatching" and "not monkeypatching" is whether it was intended,
then the only difference is what you call it.


No, it's not just a matter of what you call it.

If I lose my keys and have to break into my house, it's not
illegal. But if someone else breaks into my house without my
permission, that is illegal. It doesn't matter if the thief
*calls* it legal, there's still a difference.

--
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/HE7Z6VDDYN7RE3YIIWUKZDYBBCQCPWEG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 23/04/22 6:41 pm, Mehdi2277 wrote:
If it's allowed that a forward class may be continued in a different module I do not see how type checker like mypy/pyright could handle that. Classes are generally viewed as closed and fully defined within type checker. 


The way this kind of thing works in a statically typed language is that
the "forward" part of the definition contains all of the interface
information, so the type checker doesn't need to see the "continue"
part -- that only contains implementation.

What's being proposed here is to split the *interface* between two
class statements, and possibly different modules. That's very different.

The nearest thing I can think of in a statically typed language is the
"extension methods" of C#. The way it works there is if you want to
use any extension methods, you have to import both the module defining
the class and the module defining the extension methods.

Maybe here the client code should import the class from the module
containing the "continue class", and that module should import the
one containing the "forward class"? Would that still work to resolve
circularities?

--
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/BOO3TJ5V3LOXC2MMNFBUWIEGCNMZLKET/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 23/04/22 5:44 pm, Chris Angelico wrote:

On Sat, 23 Apr 2022 at 15:32, Larry Hastings  wrote:


Still, it's not the intent of my PEP to condone or facilitate monkeypatching.



The only difference is that you call it something
different.


To me, monkeypatching means modifying the definition of something
after the fact in a way that it wasn't designed for.

Here, the modification is fully intended, so it's not monkeypatching.

Also, as long as you can only 'continue' a class that was
previously declared 'forward', and only do it once, and can't
use a forward class until it has been continued, it doesn't
make monkeypatching any easier than it currently is.

--
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/V6VXIX4SWIRMN5GJRCN35M3OMKXQDWEF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 23/04/22 10:10 pm, Terry Reedy wrote:
'forward class' for an incomplete class is not at all clear to me.  It 
is not clear to me which part of speech you intend it to be: noun, verb, 
adjective, or adverb.  You must have some experience with 'forward' in a 
different context that makes it clearer to you.


Pascal has a "forward" keyword[1] for declaring functions, and the
term is often used for the same concept in other languages even if
it's spelled differently. So I think it would be fine here,
although "def" would also work if you want to reuse an existing
keyword.

[1] Actually it's a context-sensitive pseudo-keyword, which is
an unusual thing to find in Pascal; maybe Wirth added it as an
afterthought?

--
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/6M4MEEMNAFM6H2ST75XVNNUUSO5MY7MY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Greg Ewing]

On 23/04/22 7:22 pm, Steven D'Aprano wrote:

He said that could be
used as a very primitive form of separation of interface and
implementation, by putting the `forward class` in one module and the
`continue` in another.


But that only works if there is some way to define the interface
of the class's public attributes in the "forward" part without
also supplying their definitions. If I remember rightly the
"forward" part was only going to include the class name and
base classes.

--
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/SIK3RXO4ESGQLF5KOB6OEROH2MWTWBS6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

[Greg Ewing]

On 8/04/22 12:13 pm, Gregory P. Smith wrote:
And 
for lurkers and subscribers here to enable email notifications for 
categories of interest over there.


Is it possible to participate in a Discourse discussion entirely
by email, without having to visit the web site?

If not, then if python-dev becomes discourse-only, I will no
longer be able to follow or participate in it. I don't have the
time or energy to chase around visiting a bunch of clunky web
interfaces every day.

--
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/ANKS4G2QXS5FJ2UZJ52RZWVFXHT76QG7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Greg Ewing]

On 5/04/22 4:27 am, Coyot Linden (Glenn Glazer) wrote:

On 4/4/22 09:25, Paul Moore wrote:

I'm confused, what's wrong with """..."""? Triple quoted strings are
not exclusively for docstrings...
Paul


That isn't my reading of PEP 257, I would be happy to be wrong about this.


PEP 257 recommends that all docstrings be triple quoted, not that all
triple quoted strings be docstrings. There is a difference!

--
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/KZ2RJE7REYOYPVLOTACILLTYRJXIBPKP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Greg Ewing]

On 2/02/22 12:32 pm, Christopher Barker wrote:


I can make a "thick" high performance wrapper, e.g. if I want to call an 
expensive C function on each item in a sequence, I can do that in Cython, removing a lot 
of the overhead of Python.


"Not as fast as possible" doesn't necessarily mean *slow*. Even using
the stable ABI, the code you get will still be a lot more efficient than
a Python wrapper.

Sure, but this thread is not just about users like me, that can choose 
the more stable way or the faster way, but specifically about numpy, 
which is going to use the fast way -- and we don't want to break that 
any more than absolutely necessary.


I'm skeptical about how much difference it would actually make. Numpy
gets its speed from tight loops in C and calling out to C and Fortran
libraries. None of that is affected by which CPython API is being
used.

In any case, if numpy explicitly chooses speed over compatibility, 
that's an issue between CPython and numpy, not CPython and Cython.


--
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/UJOVLMM4OJVSGZAEVVTTNQJCNB4GWTYS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Greg Ewing]

On 2/02/22 11:53 am, Christopher Barker wrote:
As a long time Cython user, but not a Cython developer, I think (2) is 
the primary purpose, with (1) as a handy side benefit (otherwise 
we'd just use ctypes, yes?)


Personally, no, I would not "just use ctypes". The main reason I
created Pyrex was to avoid the extreme amounts of pain involved
in doing things like that.


That being said a not-quite-as-fast-as-possible mode would be fine.

Though I'm not sure it would buy much, as long as projects (including 
major ones like numpy) are using as-fast-as-possible mode.


That's why I think compatible mode should be the default. Then
those who choose otherwise will be aware of what they are doing.

It would also mean that CPython developers needn't have as many
qualms about changing internals. Cython users would be in the same
position as someone writing an extension module by hand and
choosing whether to stick to the stable API or not. If they rely
on internals, they do so at their own risk.

--
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/WTDYDJYNS7XXMXI7LVN5GOE4CVAKUIZ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Greg Ewing]

On 2/02/22 8:48 am, Guido van Rossum wrote:
It seems to me that a big part of the problem is that Cython feels 
entitled to use arbitrary CPython internals.


I think the reason for this is that Cython is trying to be two
things at once: (1) an interface between Python and C, (2) a
compiler that turns Python code into fast C code.

To address this there could be an option to choose between
"compatible code" and "fast code", with the former restricting
itself to the stable API.

--
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/EACB7ZZVDDNL4QAIODYDNWLKI455QDKP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

[Greg Ewing]

On 2/02/22 5:42 am, Victor Stinner wrote:

There is an on-going effort adding getter and setter functions on two
structures which are causing most troubles on Python updates:

* PyThreadState: https://bugs.python.org/issue39947
* PyFrameObject: https://bugs.python.org/issue40421


In the case of PyFrameObject, as far as I know the only reason
Cython needs to mess with it is to get filename/lineno information
into tracebacks. If that's still true, I think it would be better
to make it possible to add that information directly to traceback
objects so that fake frame objects are not needed.

--
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/VNNASOMXNFHRJYCUZLPWRWMXVNUIKEOU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Greg Ewing]

On 1/02/22 5:47 am, Lrupert via Python-Dev wrote:
This gives 
a bad impression to others about their intentions (constant contribution 
of trivial / low quality stuff with little-to-no-gain to achieve a 
higher number of commits, since it is a visible metric).


Or they may just feel that it's better to organise their changes into
a number of small, independent commits rather than one large one. I
wouldn't be too quick to jump to conclusions about people's motives
here.

--
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/4GZX7RHJKRRNAQSA45P7RNLHYB7F6Z6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion: a little language for type definitions

[Greg Ewing]

On 9/01/22 2:46 pm, Steven D'Aprano wrote:

if you can read expressions:

 spam(eggs | cheese,  aardvark)

then you can read type expressions:

 Spam[Eggs | Cheese, Aardvark]


That's like me saying that I can read Greek just because I know
how to pronounce the letters. I do, but that doesn't mean I
know what any of it means!

Most of the effort of learning to read type expressions, in any
language, is learning their semantics, which is very different
from value expressions. Whether they happen to superficially
resemble other parts of the language is pretty much irrelevant
to me.

--
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/AXDVYGAUCKKWOMDDHGEMEIA6PUKDCHVT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Greg Ewing]

On 17/12/21 6:58 pm, Steven D'Aprano wrote:


Or a Doctor Who episode. Doctor Who and the Immortal Instances of Doom.


Hmmm... and Guido has a time machine... Is it possible he's
secretly a Time Lord?

--
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/XVMGJRQNRCIXHAIVYNVP2HPDZVXQU7T5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

[Greg Ewing]

On 17/12/21 6:52 am, Eddie Elizondo via Python-Dev wrote:

I've just updated the original Immortal Instances PR


Is it just me, or does Immortal Instances sound like a
video game franchise?

--
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/OCO5D53ACVM7CAOIXCPC4FPKIDGDSUXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[Greg Ewing]

On 8/12/21 4:36 am, Antoine Pitrou wrote:

Is there a way to emit a compilation warning when those macros are used
as l-values? Even if only enabled on some compilers.


Maybe the macro could be written so that it expands to something
with a cast around it? I think gcc has an option for warning about
casts used as l-values.

--
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/DG6GBX6OFCK4D2G6CGQFW5QX5JXQPAZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The current state of typing PEPs

[Greg Ewing]

On 26/11/21 4:15 am, Stephen J. Turnbull wrote:

My understanding is that optional,
incremental type hints are and have always been considered the primary
use case for annotations by the BDFL


I'm not sure that's true. The way I remember it, back when
annotations were first introduced, the BDFL didn't say that,
or at least didn't say it very clearly. It sounded more like
type hints were just one of many possible uses, and he
encouraged people to experiment. There were even discussions
about coming up with a convention to manage conflicting uses
of annotations in the same code. That wouldn't have happened
if typing were considered the only supported use.

--
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/R5TWU6HTOKLCTY2QZDGEAR74TGHZHQQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: containment and the empty container

[Greg Ewing]

On 9/11/21 7:29 pm, Ethan Furman wrote:
I've had a couple people tell me that they think of flags as sets, and 
use set theory / set behavior to understand how flags and groups of 
flags should interact.


If you're going to think of flags as sets, then 'i in flags' should
be equivalent to '((1 << i) & flags) != 0'.

--
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/43SHTKMYRYSRK6P2DPG4XVZMRPOSB42E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The list.sort(reverse=True) method not consistent with description

[Greg Ewing]

On 31/10/21 5:47 am, Raymond Bisdorff wrote:
Should the tuples comparison is in this case, I thought, not be solely 
based on the first tuple component?


Whether you think it should or shouldn't, the fact is that it's not.
This is documented in Section 5.6 of the Library Reference:

"tuples and lists are compared lexicographically by comparing 
corresponding elements. This means that to compare equal, every element 
must compare equal and the two sequences must be of the same type and 
have the same length."


--
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/PJ75PNVTHPIOZ5I4HLNU67YJT2NP7FRD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is __int__ still useful for?

[Greg Ewing]

On 14/10/21 11:19 am, Greg Ewing wrote:

Not really -- __int__ is expected to return something of type
int, whereas __trunc__ is expected to return the same type as
its operand.


Scratch that, it seems __trunc__ also returns an int, at least
for floats. Not sure what the logic behind that is.

There are differences between the functions int() and trunc()
though:

>>> int("42")
42

>>> trunc("42")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: type str doesn't define __trunc__ method

Conceptually, I would say that int() is a type conversion,
whereas trunc() is an operation on numbers. A type would be
entitled to implement them both but differently.

--
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/OM5UB5LRMOSKTVGJWV3G7TP7Z7DNFE2M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is __int__ still useful for?

[Greg Ewing]

On 14/10/21 6:10 am, Antoine Pitrou wrote:

It seems that
__int__ has now become a strict equivalent to __trunc__.


Not really -- __int__ is expected to return something of type
int, whereas __trunc__ is expected to return the same type as
its operand.

--
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/5XD26XS2WW7H2I3KZBY5EZLNV64RX6VM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[Greg Ewing]

On 6/10/21 7:15 am, sascha.schlemmer--- via Python-Dev wrote:

except (*E1, *E2) as error: ...


Then we would have to decide whether to allow

except (E1, *E2) as error: ...

and if so, what it would 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/O7V4G4DWEOXNWZB6MP4PKOXV46XKVT67/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 except* formatting

[Greg Ewing]

On 4/10/21 6:23 pm, Guido van Rossum wrote:
On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > wrote:


Therefore my vote is for requiring `except* E` and keeping `except
*E` as a SyntaxError.

You can't do that with our current lexer+parser.


I don't think it would be desirable in any case. The separation of
tokens into alphanumeric and non-alphanumeric is deeply embedded in
every Python programmer's brain by now, and we shouldn't mess with
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/XQXJEGYAWBTAUQI3BEIXDZO4SERAJYWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making code object APIs unstable

[Greg Ewing]

On 2/09/21 7:46 pm, Antoine Pitrou wrote:

Tracebacks are linked in a single direction, to go the other direction
you need to walk the frames attached to the traceback. 


So a (fake or not) frame object is still desirable, IMHO.


Could we at least remove the necessity for a fake code object?

--
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/TDLCJHNQSPNE7UXEJ33PV2VNQOPUFUT7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making code object APIs unstable

[Greg Ewing]

On 2/09/21 4:46 am, Victor Stinner wrote:

If creating a fake frame is a common use case, we can maybe write a
public C API for that. For example, I saw parser injecting frames to
show the file name and line number of the parsed file in the
traceback.


The way I would like to see this addressed is to make it possible
to attach a filename and line number directly to a traceback object,
without needing a frame or code object at all.

Creating a fake frame and code object just to do this is IMO an
ugly hack that should not be necessary.

--
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/XWX7EXJQ3JJRAL26YFR3GSSMLGSCEH2V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Dropping out of this list

[Greg Ewing]

On 19/08/21 7:23 pm, Antoine Pitrou wrote:

The whole thing is ridiculous enough to read like a Monty Python skit by
now, but the trout-slapping ending is still missing.


Just have the police come in and arrest everyone, that
usually works.

--
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/NRVEWJUUVGYLKQDAUQ4R5PFFNRX7KR5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

[Greg Ewing]

On Wed, May 26, 2021 at 8:55 AM Ammar Askar > wrote:


most
recently if your topic mentioned libera.chat, the new freenode owners
will take it over, ban anyone from chatting in it and change the topic


My goodness. Let's hope the new owners eventually learn that behaving
like spoilt 7-year-olds is no way to run a successful company.

--
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/BOUNCG5BAMXND5LXDH553F6TEHJGZ4MM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In what tense should the changelog be written?

[Greg Ewing]

On Fri, Apr 30, 2021 at 02:22 Steven D'Aprano > wrote:


Without a subject of the sentence, that's not present tense, it is the
imperative mood.


     "Fix buffalo.spam ..."

is a command or suggestion.


While it could be read that way, I don't think that's the intention.

I'm not sure it fits any of the usual grammatical categories. It
might be best understood as an abbreviated infinitive, i.e. there's
an implied "The purpose of this commit is to..." in front of 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/LWB7RV67BIYZILBYDPNZC7INS2RFMMM4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Boundaries between numbers and identifiers

[Greg Ewing]

On 14/04/21 8:54 am, Guido van Rossum wrote:
On Tue, Apr 13, 2021 at 12:55 PM Serhiy Storchaka 
>

  >>> [0x1for x in (1,2)]

I would totally make that a SyntaxError, and backwards compatibility be 
damned.


Indeed. Python is not Fotran!

--
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/WBZ2IQFNL2ICZ6WCMURCXXHDDTWWCWIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Greg Ewing]

On 7/04/21 5:22 am, Brandt Bucher wrote:

we might consider updating those templates if the term "Reference Implementation" implies 
a higher standard than "we've put in the work to make this happen, and you can try it out 
here"


Maybe "prototype implementation" would be better? I think I've used
that term in PEPs before.

--
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/HLDVEIN5EKTE3KJOZRXZMPOOIUAE4VFB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Greg Ewing]

While we're talking about compelling use cases, does anyone have an
actual, concrete use case for the proposed "except *" feature that's
strong enough to justify new syntax?

I'm fine with having ExceptionGroup as a built-in type. I'm not fine
with adding new syntax that will apparently be used only in rare
circumstances.

Can code that's aware of the possibility of getting an ExceptionGroup
not simply catch it as a normal exception and then pick it apart? Do
we really need a whole new piece of machinery for this?

--
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/EIW6JGXRWKEEIY72CGZ7BMKU3LHJIZQK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Greg Ewing]

On 4/03/21 5:37 am, Paul Moore wrote:

frameworks and libraries typically have to interact with other users'
code, and there the contract has changed from "do what you like in
your code and I'll cope" to "do what you like in your code as long as
you don't let an exception group escape, and I'll cope"... And I have
to change *my* code to get the old contract back.


Seems to me this whole issue would go away if the ordinary
except statement were to look inside ExceptionGroups.

In other words, the only difference between except and
except* would be that multiple except* clauses can be run,
whereas only one except clause will run (the first one that
matches something in the ExceptionGroup).

Is there any good reason not to do things that way?

--
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/NDIO4533M4OQZZWT65EKPPIXZU6ZJQUY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Greg Ewing]

While I don't particularly mind if we get ExceptionGroup, giving
it special magical semantics, and especially new syntax, seems like
bringing a massively overpowered weapon to bear on something that
will only be used rarely.

Handling multiple exceptions from an ExceptionGroup could be done
using a loop with pattern matching, so is except* really justified?

--
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/BRQDP4KNRYU6UCKQBHRAUAHWWCENNIVM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Greg Ewing]

On 14/02/21 8:48 am, Eric Traut wrote:


def is_str_list(val: Constrains[List[object]:List[str]) -> bool:
 ...


Maybe something like this?


def is_str_list(val: List[str] if True else List[object]) -> bool:
   ...

--
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/GLHQVM7NIYO2GZHGREJ5FE2KJ7AI3DTQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Greg Ewing]

On 13/02/21 9:03 am, Paul Bryan wrote:

What if PSF were to undertake codifying a language specification?


We have the Language Reference and Library Reference. Do they
not count as specifications?

--
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/EUYJ6W3TKQNSE6EOBQL4W4F2UJDUIDL6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Greg Ewing]

On 7/02/21 9:58 am, Steve Holden wrote:
My suggestion that it be introduced via __future__ due to its 
contentious nature met immediate resistance.


__future__ is for things that are changing in incompatible ways.
This is an entirely new feature that doesn't conflict with anything
existing, so it doesn't need __future__.

--
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/T3CJQWO7DQEJPECHUYJH655D75LMVOVM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What's up with assignment expression and tuples?

[Greg Ewing]

On 5/02/21 8:51 pm, Paul Sokolovsky wrote:

a = 0
while a < 5:
 a += 1


becomes:


a0 = 0
while (a1 := phi(a0, a2)) < 5:
 a2 = a1 + 1


SSA seems to be something intended for compilers to use as an
intermediate representation, not something to actually write
code in. So I'm puzzled as to why you would want to do this.

Also, what definition do you have in mind for phi? It doesn't
seem to be something you can implement as a real function.

--
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/UBXNDF4QL7I2IWQSUTIPCNLZXGOCG23D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Greg Ewing]

On 3/02/21 10:35 pm, Phil Thompson wrote:

On 02/02/2021 23:08, Greg Ewing wrote:

you have no idea what
kind of C struct it expects to get.


I had assumed that some other magic in typeobject.c (eg. conflicting 
meta-classes) would have raised an exception before getting to this 
stage if there was a conflict.


"No idea" is probably an exaggeration -- there is checking
to ensure that all the C structs involved form a sequence
of extensions. But they still need to be initialised in the
right order, because __new__ methods for later ones assume
that the struct they're extending has already been
initialised.

--
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/N54L3266FSMKEQPFPH3YS3XZ6GVJMGAU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Greg Ewing]

On 3/02/21 11:05 am, Martin Teichmann wrote:


     class MyClass(B, Mixin):
           "whatever"

this leads to an MRO of MyClass -> B -> Mixin -> A -> object.


If you do the tp_new stuff correctly at the C level, you can still
create such a class. The only limitation is that if Mixin has a __new__
method written in Python, it won't get called. So if Mixin needs to
do any initialisation, it will have to be in __init__, *and* all the
__init__ methods in the chain will need to be designed for
cooperative calling.

--
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/YOMFSCDKYYFNV4IRGFAMLQU7WQYNTO6C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Greg Ewing]

On 3/02/21 4:52 am, Phil Thompson wrote:

Thanks - that's fairly definitive, although I don't really understand 
why __new__ has this particular requirement.


The job of tp_new is to initialise the C struct. To do this,
it first has to initialise the fields of the struct it
inherits from, then initialise any fields of its own that
it adds, in that order.

Initialising the inherited fields must be done by calling
the tp_new for the struct that it inherits from. You don't
want to call the tp_new of some other class that might have
got inserted into the MRO, because you have no idea what
kind of C struct it expects to get.

Cooperative calling is a nice idea, but it requires rather
special conditions to make it work. All the methods must
have exactly the same signature, and it mustn't matter what
order they're called in. Those conditions don't apply to
__new__, especially at the C level where everything is much
more strict type-wise.

--
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/5AGXKE35LDQA6JP6EKXW7FUFR7YCC3RR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Greg Ewing]

On 3/02/21 12:07 am, Phil Thompson wrote:

On 01/02/2021 23:50, Greg Ewing wrote:

At the C level, there is always a *single* inheritance hierarchy.


Why?


Because a C struct can only extend one other C struct.

I want my C-implemented class's __new__ to support cooperative 
multi-inheritance


I don't think this is possible. Here is what the C API docs have to
say about the matter:

---

Note

If you are creating a co-operative tp_new (one that calls a base type’s 
tp_new or __new__()), you must not try to determine what method to call 
using method resolution order at runtime. Always statically determine 
what type you are going to call, and call its tp_new directly, or via 
type->tp_base->tp_new. If you do not do this, Python subclasses of your 
type that also inherit from other Python-defined classes may not work 
correctly. (Specifically, you may not be able to create instances of 
such subclasses without getting a TypeError.)


---

(Source: https://docs.python.org/3.5/extending/newtypes.html)

This doesn't mean that your type can't be used in multiple inheritance,
just that __new__ methods in particular can't be cooperative.

--
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/KVUEGIRAXWPVD6BZLHPKUI5X7UBH3G2M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding "is not safe" in typeobject.c

[Greg Ewing]

On 2/02/21 12:13 am, Phil Thompson via Python-Dev wrote:

TypeError: object.__new__(B) is not safe, use B.__new__()


It's not safe because object.__new__ doesn't know about any
C-level initialisation that A or B need.

At the C level, there is always a *single* inheritance hierarchy.
The right thing is for B's tp_new to directly call A's tp_new,
which calls object's tp_new.

Don't worry about Python-level multiple inheritance; the
interpreter won't let you create an inheritance structure
that would mess this up.

--
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/IW3OX6Y324VSF4WLQHGA7EFHJQ6XEBH4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 19/01/21 1:13 pm, Inada Naoki wrote:

I don't want to import modules used only in type hints. I don't want
to import even "typing".


How about having a pseudo-module called __typing__ that is
ignored by the compiler:

from __typing__ import ...

would be compiled to a no-op, but recognised by type checkers.
If you want to do run-time typing stuff, you would use

from typing import ...

--
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/24MR5KVWP7LR3PCE7V44OTLJNXDLLNZX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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 __co_annotations__.

--
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/PPDBI3J4SUJ6NCWRORWYAOKYW4IM3HMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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

[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

[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: 3.10 change (?) for __bool__

[Greg Ewing]

On 14/01/21 3:32 pm, Terry Reedy wrote:
I say 'yes', because the purpose of logging is to document what happens, 
and if nothing happens, there is nothing to document.  Wrapping a 
.__bool__ in a logging decorator might be part of testing it.


Or it might be something else.

It would be fine to *define* __bool__ as something the compiler
is allowed to optimise away. But that's a different thing from
"purity" (which is hard to pin down in an imperative language).

--
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/FKQSB6SVOAO2Y3BOQSXSHEN5LM2KBETR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 14/01/21 1:13 pm, Paul Sokolovsky wrote:

But nobody talked about optimizing away generic "pure"-annotated
functions (which would differ from "mathematical" definition of
purity), only about optimizing "pure" *dunder* methods


The same thing applies. If we decide that print() is pure,
then a __bool__ that calls print() is also pure, so there's
nothing wrong with optimising it away, right?

--
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/KFP2TZXVJAQROMILOOM3CJT24DJESBHJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 14/01/21 6:17 am, Paul Sokolovsky wrote:

For
example, print() would be considered "pure", as its purpose is to
provide program output, not arbitrarily change program state


That definition of purity wouldn't really help with optimisations,
though, because optimising away a print() call would still cause
a visible change in the program's behaviour.

--
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/B6VDVU7UOB5QNILEJ44J7JOSVBF7WDBF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 14/01/21 5:29 am, Steven D'Aprano wrote:

No, I don't think it is possible to enforce lack of side-effects. Not
without rebuilding the language from the ground up with a clear,
definitive and enforcable distinction between pure and impure functions.

(I think Haskell does something like that.


All functions are pure in Haskell -- not sure if that counts
as "doing something like that". Retrofitting it into
Python would turn it into a very different language.

--
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/7BOWX7N54CA6FPGJDCQSEH73MQZKJEEE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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 do we know 
which set of semantics we need to use?


This implies that __future__ is the wrong mechanism to use.
It's only appropriate when the changes it triggers are confined
to the module that uses it, which is not the case here.

--
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/3R3U2DSRVJRPFCXFCGMZG7KRK53THSGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 13/01/21 5:47 am, Larry Hastings wrote:


instead of the compiler storing a code object as the annotations 
argument to MAKE_FUNCTION, store a tuple containing the fields you'd 
need to /recreate/ the code object at runtime--bytecode, lnotab, names, 
consts, etc.


Would that tuple be significantly smaller than the corresponding
code object, though?

--
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/2NHFIGK55XN4U77V6V2KTBRGJ7TSGAAB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 13/01/21 6:54 am, Larry Hastings wrote:
Note that this only works in the current version of the PEP / prototype, 
where annotations are strictly evaluated in module scope.  If we start 
supporting closures, those need "cell" objects, which IIUC can't be 
marshalled.


The cells belong to the enclosing scope, not the function that uses
them. I don't think they would interfere with sharing parts of code
objects between identical annotations.

--
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/QKMYWGBSQKNFUNBHXXWFJZ7WIRHGTEWI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 12/01/21 2:56 pm, Larry Hastings wrote:


In PEP 649 I think every reference of "binding" is talking 
about binding a code object to a globals dict to produce a function 
object.   The process of binding a function to an object instance to 
make a method is conceptually very similar, but distinct.


Maybe "bare code object" would be a less confusing term?

--
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/EMVOMYUEQN3ZV5Y2P5B4NEZEJ2KMJTLM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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", "copyright", "credits" or "license" for more information.
>>> class C:
...  __slots__ = ['a', 'b']
...
>>> class D(C):
...  __slots__ = ['c', 'd']
...
>>> class E(D):
...  pass
...
>>> C.__slots__
['a', 'b']
>>> D.__slots__
['c', 'd']
>>> E.__slots__
['c', 'd']
>>>

--
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/L3OFSRVV6DGB4LXO6GY3WW7PBC2VY7AD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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 object could be used for all
annotationless objects.

--
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/FEFCXJY52F67R6XEHS4NA3HL6MB4X3I2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 12/01/21 11:32 am, Łukasz Langa wrote:


EdgeDB uses stringified annotations exclusively which 
minimizes runtime memory usage of annotations because those strings are 
pretty much all ASCII and many can be interned.


946 -> s_schema.Schema
362 -> str
298 -> sd.CommandContext


Seems to me the code objects for those would be identical
wherever they're used, and so could be cached and re-used
the same way as interned strings.

--
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/MYI2JXMBR52HGVL46DRM2KW5T34GC7OP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 12/01/21 10:41 am, Larry Hastings wrote:


So: if you're using annotations for something besides "type hints",


Didn't Guido decree that using annotations for anything other than
type hints is no longer supported?

--
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/GP5PHEAGY4USPDLLMWUG52CGQQ3K4AKI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 12/01/21 10:16 am, Larry Hastings wrote:
This is addressed in PEP 563, when it rejected the idea of using 
"function local state when defining annotations":


This would be prohibitively expensive for highly annotated code as
the frames would keep all their objects alive. That includes
predominantly objects that won't ever be accessed again.


I'm not sure what that's supposed to mean.

Firstly, functions that reference nonlocal names don't keep whole
frames alive, only the particular objects they reference.

Secondly, if an annotation references something at module level,
that something will also be kept alive unless it is explicitly
removed from the module -- which could also be done at a local
level if you didn't want to keep those things around.

So I don't really see any difference between global and local
state when it comes to things being kept alive by annotations.

--
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/GEO6SQL2ZN4KR5A72RK3OGEN4SZQM4TK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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
None.

If we're changing things, I'm wondering if the best thing would be
to introduce an annotations() function as the new best practice for
getting an object's annotations. It would know how to handle all
the type-specific pecularities, and could take care of things such
as manufacturing an empty dict if the object doesn't have any
annotations.

--
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/DXQJ2V32YIV5KZQNFSPFVGKKVHIZDFPD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 12/01/21 6:21 am, Larry Hastings wrote:


Unbound code objects


...The "annotation code object" is then stored *unbound*
as the internal value of ``__co_annotations__``; it is then
bound on demand when the user asks for ``__annotations__``.


This seems like premature optimisation. Function objects are
tiny compared to the code object, which is already a fairly
complicated thing composed of a number of sub-objects.

--
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/H7VGQG5YS6LUJGRQH5RHTC7HUUMH64NG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Story behind vars() vs .__dict__

[Greg Ewing]

On 9/01/21 9:12 am, Chris Barker wrote:
(though I notice that if you create __slots__ in pure Python, its names 
show up in dict anyway -- so clearly I'm confused...)


Descriptors for the slots get added to the *class* dict.
But that's not the dict that vars() looks at.

--
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/IVGKEFTRXTSS7MHLH6G4RMJ4INM4LYZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancement request for PyUnicode proxies

[Greg Ewing]

Rather than a full-blown buffer-protocol-like thing, could we
get by with something simpler? How about just having a flag
in the unicode object indicating that it doesn't own the
memory that it points to?

--
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/UJTXHTVGG63F6GMGIL4TW6KKLHU7V4DN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Story behind vars() vs .__dict__

[Greg Ewing]

On 22/12/20 12:36 am, Paul Sokolovsky wrote:

Expected clarification on ".__dict__ breaking object encapsulation":


Encapsulation is not something that Python has ever been big
on. There are plenty of places where implementation details are
exposed, and we don't regard that as a problem.

--
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/BFK7LTKHZ5JLEKUPZXF5AQ3WMGODL4F5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Greg Ewing]

On 10/12/20 10:28 am, Guido van Rossum wrote:
In my experience Apple hardware is very reliable and way outlives the OS 
updates. Even if an OS updates is still available, the newer OS often 
needs more memory, which can be a problem


Another problem, for me at least, is that OS updates often seem
to remove functionality that I like and rely on. I stuck with
10.6 for a very long time, because it did everything I wanted,
and there were some third party extensions I used that stopped
working in 10.7 and there were no good replacements available.

--
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/57DWVZDDJNXBNT6UKGSFH5STJHYREAHO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[Greg Ewing]

On 24/11/20 9:44 am, David Mertz wrote:

m = Matcher(arbitrary_expression)
if m.case("StringNode(s)"):
     process_string(m.val)
elif m.case("[a, 5, 6, b]"):
     process_two_free_vars(*m.values)
elif m.case("PairNone(a, b)"):
     a, b = m.values
     process_pair(a, b)
elif m.case("DictNode"):
     foo = {key, process_node(child_node) for key, child_node in 
m.values.items()}


How does the Matcher object know the meanings of "StringNode",
"PairNode", etc.? Presumably they're bound to classes in the
namespace of the caller, but the Matcher doesn't know anything
about that namespace.

--
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/DVEMPPHHVZORWBNWVWJOJZHJMKYYEJ2H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

[Greg Ewing]

On 24/11/20 9:31 am, Brian Coleman wrote:

In my opinion, the object oriented solution to this problem is to use the 
visitor pattern.


Which is a good thing only if you believe that OO solutions are
always better than non-OO ones.

IMO, the visitor pattern is a workaround for when your language
doesn't permit introspection on types. It's unnecessary in
Python and better avoided.

--
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/XZ2EKVMQXZ5DEV5TWLBKGNU5JWFMIX4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Greg Ewing]

On 23/11/20 7:49 am, Daniel Moisset wrote:

Look at the following (non-pattern-matching) snippet:

event = datetime.date(x, month=y, day=z)


The only names that are treated as lvalues there are to the left
of an '='. The rules are a lot simpler.

One of the Zen lines says "If it's hard to explain, it's probably
a bad idea." I think the proposed rules for match cases are
objectively harder to explain than those for other expressions,
because they're more complicated.

--
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/AVXFD6J2LGGTJH5LZKBJ3EAGUPV6QPGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Greg Ewing]

On 22/11/20 1:07 pm, Henk-Jaap Wagenaar wrote:
On Sat, 21 Nov 2020 at 19:58, Glenn Linderman > wrote:


Don't () already indicate an expression to be evaluated?

Does it?

[(a, b)] = [(0, 1)]


Presumably a comma would be needed to match a 1-tuple.

   case (x): # matches the value of x

   case (x,): # matches any 1-tuple and binds x

--
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/4T3OFJEIGMZEW5QJ3WXFAICK6LZD3P5Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Greg Ewing]

On 22/11/20 6:47 am, David Mertz wrote:
I'm convinced by Guido, 
Brandt, and others that the binding  use will be far more common, so 
adding extra characters for the 90% case does not feel desirable


Minimising the number of characters is not the only consideration.
Readability counts too, and I think the proposed DWIM rules suffer
in the readability area.

There are about five different contexts in which a bare name can
appear as part of a match case:

* As a constructor name
* As a bare name in an argument position
* As part of a dotted expression
* On the left of an =
* On the right of an =

Only in some of those contexts is it treated as a name to be
assigned. That's a fairly complex bit of mental parsing to do
when reading a case.

--
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/LMALNSPBLL3MHFOJHBGGO24IDS6CI5R3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Greg Ewing]

On 18/11/20 5:29 pm, Stephen J. Turnbull wrote:

Glenn Linderman writes:

  > Mathematics never came up with separate symbols for equality and
  > assignment.

Mathematics doesn't need them, until we come to an age where we do
mathematics on algorithms.


Even then, when mathematicians describe algorithms they often
use subscripts to disinguish different values of a variable on
different iterations, effectively making them into different
variables. So they still don't need a symbol for assignment.

--
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/H7KT3RGEJACTHPLL6DFQRHDWHZHZAX33/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

[Greg Ewing]

On 18/11/20 4:36 pm, Larry Hastings wrote:


But, 
the thinking went, you'd never want to examine the last value from a 
list generator, so it was more convenient if it behaved as if it had its 
own scope.


List comprehensions used to leak, but apparently that was considered
surprising by enough people that it was changed.

Generator expressions are a bit different -- the only sane way to
implement them was to make the body implicitly a separate function,
and non-leaking behaviour naturally fell out of that. Making them
leak would have taken extra work just to get something that nobody
really had a good use case for.

The desire to make list comprehensions and generator expressions
behave consistently may have contributed to the decision to change
list comprehensions to be non-leaking.

So yes, it's all a bit messy, for reasons that are partly historical
and partly pragmatic, but things seem to work out okay in practice
most of the time.

If there's anything I would change, it would be to have the for
statement create a new binding on each iteration, so that capturing
it with a def or lambda inside the loop works as expected. I even
came up with a way to do that while still allowing the last-bound
value to be seen afterwards, but the idea didn't gain any traction.

--
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/FC7WYLN7C54ZK2FRQSLH5GFA4P2OHBBC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[Greg Ewing]

On 15/11/20 10:48 pm, Paul Sokolovsky wrote:
> [from PEP 635]

Pattern matching is complimentary to the object-oriented paradigm.


BTW, there seems to be a typo here -- I think it's
meant to be "complementary".


please explain why you chose to proceed anyway (and apply workarounds),
instead of first introducing the concept of constants to the language.
(Given that amount of work to implement pattern matching is certainly
an order of magnitude larger than to introduce constants)."


That's not certain at all, and moreover it's not just a matter of
work, it's a language design issue that would require its own
extensive investigation and debate. Members of the intended audience
(people very familiar with Python and its technicalities) can be
expected to understand this, so the PEP doesn't need to spell it out.


How to support multiple variable scopes in one stack frame is not a
rocket science at all. One just need to remember how C did that


We can't just do it "like C does" because C requires variables to
be declared and Python doesn't.


The only reasons for not implementing the same solution in Python would
be intertia of thought and "but it's not done anywhere else in
Python".


No, other reasons include that it would require making unrelated
language changes that open various other wormcans.


nobody del'eted local variables behind users' backs
either, before somebody started to do that for exception clause
variables.


There was a good reason for that having to do with reference cycles.
Nobody liked it much, but we didn't really have a choice. There is
no such pressing need for special scope rules in match statements.

--
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/MUCUIUF5LSQOBJDZW3OVHH253GIJBVDN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Greg Ewing]

On 14/11/20 9:33 am, Jim J. Jewett wrote:

I *hope* this was a typo!  If

 case Point(x=a, y=b):

assigns to a and b (instead of x and y, as in a normal call), then that is ... 
going to be very easy for me to forget, and to miss even when I'm aware of it.


I don't think it is a typo, unfortunately.

I share this concern, and it's one of the reasons I would prefer
assignments to be explicitly marked. With

   case Point(x=?a, y=?b):

then if you get it wrong and write

   case Point(?a=x, ?b=y):

at least you'll get a syntax error.

--
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/JOMGBETRPYWVMRIM3UXZVG422J5TCBCT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Greg Ewing]

On 14/11/20 7:45 am, Brandt Bucher wrote:

with (using your own syntactic flavor):
```
case >first, *>middle, >last:
 rebuilt = first, *middle, last
case {"key": >value, **>rest}:
 rebuilt = {"key": value, **rest}
case Point(x=>a, y=>b):
 rebuilt = Point(x=a, y=b)


I think this is a case where syntax matters. To my eyes this
looks far less confusing:

case ?first, *?middle, ?last:
 rebuilt = first, *middle, last
case {"key": ?value, **?rest}:
 rebuilt = {"key": value, **rest}
case Point(x=?a, y=?b):
 rebuilt = Point(x=a, y=b)

> (I had to stop and think *hard* where exactly the `>` should go in 
>`*middle` and `**rest`.


There's a simple rule -- the "?" goes directly in front of the
thing being assigned. You're assigning to 'middle', not '*middle',
so it's '*?middle', not '?*middle'.

I know the same rule applies whatever sigil is being used, but
to my way of thinking, '>' is too easily confused with a comparison
operator. Also it's tempting to interpret '=>' as a single token,
which accidentally happens to make sense here, but could mislead
people into writing '*=>middle' instead of '*>middle'.

--
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/EQQ4Z4YZ7DCSHTMPUL4P33W4VKXWPZ65/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Greg Ewing]

On 13/11/20 9:19 am, MRAB wrote:
I'd still want to list "as" as another possibility, the advantage being 
that it's already used for binding elsewhere.


Only where it makes English grammatical sense, though, which
it doesn't unless there's something on both sides.

--
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/CPXF3P2Y6GJFU2NFBAYKZDH56QQA3NQM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Greg Ewing]

On 13/11/20 8:21 am, Paul Sokolovsky wrote:

The current stage is to accept
the fact that "mark capturing terms" is *very viable* alternative to
"mark terms to use as values" ... But people
behind PEPs keep ignoring that choice - silently, or with minimal
consideration/commentary.


Their stated justification for this is that capturing will be
used much more often than value matching. I'm not convinced about
that -- how do they know? This is a feature unlike anything
Python has had before. I don't think we can predict how people
will use it.

Even if it's true, this seems to be prioritising writability
over readability.

Marking the captures would be my preferred choice. I don't like
the idea of DWIM heuristics for distinguishing values from
captures, I'd prefer everything to be explicit. And it seems
more logical to me to mark the captures rather than the values.

The vast majority of expressions in Python are interpreted as
values, and assignment targets only occur in a few specially
marked places -- on the LHS of an assignment, after "as", etc.
I think the same principle should apply in match statements.

The only real disadvantage I can see is that it would make
pattern matching substantially different from unpacking, but
it's been stated that making these compatible is a non-goal,
maybe even an anti-goal, and I'm fine with that.

--
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/GURVGWAILH2BAJOEBQU33DVDV4I2ZYCC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My thoughts on Pattern Matching.

[Greg Ewing]

On 7/11/20 4:03 am, Thomas Wouters wrote:

It's also why I'm not in favour of PEP 642 and other proposals for 
solving some of the problems in the Structural Pattern Matching proposal 
(sigils, etc): it widens the gap instead of closing it.


Does that mean you're against *any* proposal that involves sigils, or
just PEP 642 in particular?

Also, I'm very confused about why you're against PEP 642. It seems to
do a good job of meeting your stated goals -- syntax in common between
unpacking and matching has the same meaning, and the way is left open
for making them more like each other in the future. Can you elaborate
on what you don't like about 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/2X3IME7SD6HOA6D5HRHWR3VSSDKEOGUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Greg Ewing]

On 6/11/20 4:54 am, Steven D'Aprano wrote:

On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote:


If "_" is a non-binding wildcard, linters will have to allow
"case _, _" otherwise it might as well not be there. And then
if it is later changed to be binding,


Why would we want to do that?


I'm not suggesting we should. I was replying to a post proposing
to not treat "_" specially, and pointing out that if we don't
make it special now we can't change our mind later.

--
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/3TJC6U7LQOTOZGZVMTP4XXVMGQK6NQP3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Greg Ewing]

On 4/11/20 4:36 am, Paul Svensson wrote:

On Tue, 3 Nov 2020, Greg Ewing wrote:


once people start using "_" as a wildcard
in patterns, it will be too late to go back.


But will it, really ?
It seems to me, that if we leave the "_" magic out,
and leave "case x, x" to the linters,
that leaves a clear path forward
for whatever can be decided whenever it can be decided.


If "_" is a non-binding wildcard, linters will have to allow
"case _, _" otherwise it might as well not be there. And then
if it is later changed to be binding, "case _, _" will
either become invalid or start forcing the two occurrences to
be equal, depending on which change is made, thus breaking
existing code.

The only way I can see to keep our future options open in this
area is not to have a wildcard at all, and make people use
a different throwaway name for each don't-care position in a
pattern.

--
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/RVTWRZ7NM2OWLCXFXJLNYA66GKXYHADN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Greg Ewing]

On 3/11/20 11:01 am, Ethan Furman wrote:


I believe supporting

     case x, x   # look ma!  no guard!

is a possible future enhancement.


In which case there will be a need for *some* kind of true
"don't care" placeholder. If it's not "_" then it will have
to be something else like "?". And we need to decide about
it now, because once people start using "_" as a wildcard
in patterns, it will be too late to go back.

--
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/CIMR47FNVET4427SUXYWM46LGRAO7JQH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

[Greg Ewing]

On 31/10/20 7:22 am, Mark Shannon wrote:

On 30/10/2020 4:09 pm, Brandt Bucher wrote:
Anyone who reduces pattern matching 
to "a fancy switch statement" probably isn't the right person to be 
discussing its semantics and usefulness with.


Pattern matching is a fancy switch statement, if you define "fancy" 
appropriately ;)


I think Brandt's point is that it sounded as though you were making
a derogatory remark about the statement option, and that people are
likely to stop listening to someone who does that kind of thing.


OOI, what is the reasoning for choosing a statement, not an expression?


Which is a *much* better way to say what I think you were trying to
say.

--
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/RDGU4WSVWVSW7GD3SDAA6W7U6ZXKEZ4E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: os.scandir bug in Windows?

[Greg Ewing]

On 27/10/20 8:24 am, Victor Stinner wrote:

I would
rather want to kill the whole concept of "access" time in operating
systems (or just configure the OS to not update it anymore). I guess
that it's really hard to make it efficient and accurate at the same
time...


Also it's kind of weird that just looking at data on the
disk can change something about it. Sometimes it's an
advantage to *not* have quantum computing!

--
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/GPWWYOB3EQKDLELTYTE4IWGQ726BCPSY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: fail keyword like there is pass keyword

[Greg Ewing]

On 24/10/20 7:52 am, Umair Ashraf wrote:

class MyTest(unittest.TestCase):
    def test_this_and_that(self):
       """
       Given inputs
       When action is done
       Then it should pass
       """
       fail


def fail():
raise Exception("It didn't work!")

Not every one-line function needs to be a keyword!

I feel this *fail* keyword is needed to write a 
test first which fails and then write code and then come back to the 
test and fill its body.


Um, that's not quite how TDD is supposed to work. You don't explicitly
write the *test* so that it fails. You write a proper test, and it
fails initially because you haven't yet written the code that it tests.

--
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/5PHQ6FMCOF7LSBYLIP5KWMEPSDEUU7MM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Greg Ewing]

A concern I have about this is what effect it will have on the
complexity of CPython's implementation.

CPython is currently very simple and straightforward. Some parts
are not quite as simple as they used to be, but on the whole it's
fairly easy to understand, and I consider this to be one of its
strengths.

I worry that adding four layers of clever speedup tricks will
completely destroy this simplicity, leaving us with something
that can no longer be maintained or contributed to by
ordinary mortals.

--
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/6XBJ2OA46KNMJ6FFI3B6RFYRTTD4HYOI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: os.scandir bug in Windows?

[Greg Ewing]

On 20/10/20 4:52 am, Gregory P. Smith wrote:
Those of us with a traditional posix filesystem background may raise 
eyeballs at this duplication, seeing a directory as a place that merely 
maps names to inodes


This is probably a holdover from MS-DOS, where there was no separate
inode-like structure -- it was all in the directory entry.

--
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/QJVZ2EXFKCMZ4YHERFI2FXJTWWPFCFSA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing Python's string search algorithms

[Greg Ewing]

On 17/10/20 3:26 pm, Tim Peters wrote:

Tal Einat posted earlier that he was keen to try to work up a clear
explanation, and I look forward to that. All the expositions I've
found of this algorithm so far are hard to approach.


Maybe Mathologer or 3blue1brown could be persuaded to help?
They seem to have a knack for making tricky stuff understandable.

--
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/BE3B7K5BTKCJQ63L6RFHW6ZPSQEG67OQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing Python's string search algorithms

[Greg Ewing]

On 15/10/20 1:45 pm, Chris Angelico wrote:

So it'd
be heuristics in the core language that choose a good default for most
situations, and then a str method that returns a preprocessed needle.


Or maybe cache the results of the preprocessing?

--
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/EH26IH753UX3PSURGN5GUKEKX6QDANEZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding why object defines rich comparison methods

[Greg Ewing]

On 23/09/20 12:20 am, Steven D'Aprano wrote:

Presumably back when rich comparisons were added, the choice would have
been:

- add one tp_richcompare slot to support all six methods; or

- add six slots, one for each individual dunder

in which case the first option wastes much less space.


I don't know the exact reasons, but it might also have been
because the implementations of the six dunders are usually
very closely related, so having just one function to implement
at the C level is a lot easier for most types.

Also remember that before tp_richcompare existed there was
only tp_compare, which also handled all the comparisons, so
tp_richcompare was likely seen as a generalisation of that.

--
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/SD2YPQSBV3MQ3GGNHVGRM3QM7WEBCTKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

[Greg Ewing]

On 22/09/20 10:06 pm, Victor Stinner wrote:

I wrote a simple implementation which leaves the code as it
is, but "unbox" tagged pointers when a function access directly object
members. Example in listobject.c:

 vl = (PyLongObject*)_Py_TAGPTR_UNBOX(v);
 wl = (PyLongObject*)_Py_TAGPTR_UNBOX(w);
 v0 = Py_SIZE(vl) == 0 ? 0 : (sdigit)vl->ob_digit[0];
 w0 = Py_SIZE(wl) == 0 ? 0 : (sdigit)wl->ob_digit[0];


I think you're using the terms "box" and "unbox" the opposite
way from most people. Usually a "boxed" type is one that lives
on the heap, and an "unboxed" one doesn't.


My first goal was to write a *correct* (working) implementation, not
really an optimized implementation.

That's why I'm calling for help to attempt to optimize it ;-)


What are you trying to achieve by using tagged pointers?

It seems to me that in a dynamic environment like Python, tagged
pointer tricks are only ever going to reduce memory usage, not
make anything faster, and in fact can only make things slower
if applied everywhere.

We already have ways of efficiently storing collections of ints
and floats -- array.array, numpy, etc. -- and you only pay for
the overhead of those if you need them.

--
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/QWWQA2U6M3JLQHQNCWJ4MROISHBDNW3I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Hygenic macros PEP.

[Greg Ewing]

On 16/09/20 4:54 pm, Guido van Rossum wrote:
I'm not entirely sure how this would preserve the hygiene of the macros 
though,


Despite the title of the PEP, it doesn't actually propose to enforce
hygiene either, it just gives some suggested guidelines for macro
processors to do it themselves.

--
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/QP2W7V425357MKFJ3R7J3M3V42MIE5MN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Hygenic macros PEP.

[Greg Ewing]

On 16/09/20 12:37 pm, Guido van Rossum wrote:
IMO if we were to standardize the AST for times immemorial this would 
have to be a separate PEP.


Perhaps, but a stable AST seems to be a prerequisite for this kind
of feature. Preferably one that corresponds as closely as possible
to the language syntax so that users can keep it in their heads.

Maybe the PEP should propose an AST of its own, which would initially
be a third thing separate from either of the existing ones, with
the possibility of adopting it as the ast module representation
some time in the future.

--
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/4HPFUMTERAFB6M3CKE7GJOD2JWOWZTIU/
Code of Conduct: http://python.org/psf/codeofconduct/