[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Thu, Jun 25, 2020 at 8:31 PM Richard Damon 
wrote:

>
> I thought _ was also commonly used as:
>
> first, -, last = (1, 2, 3)
>
> as a generic don't care about assignment. I guess since the above will
> create a local, so not overwrite a 'global' function _ for translations,
> so the above usage works as long as that function (or whatever namespace
> you are in) doesn't use _ for translations. As long as the bindings in
> match also make the symbol a local (which seems reasonable) then you
> would get a similar restriction.
>

The PEP currently says:

"The named class must inherit from type. It may be a single name or a
dotted name (e.g. some_mod.SomeClass or mod.pkg.Class). The leading name
must not be _, so e.g. _(...) and _.C(...) are invalid. Use object(foo=_)
to check whether the matched object has an attribute foo."
___
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/EAMFUFSEPZFABBMD3EWASUS5YQOA26YQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Carl Shapiro]

Thank you very much for putting this PEP together.

It would be very helpful to broaden the objective of avoiding functions
returning PyObject** to other types of pointers.  I have in mind several
functions in the C-API that return a char* pointer to the contents of an
object.  While these functions are easy to implement on top of the CPython
object model they are challenging for alternative Python implementations.

Consider PyBytes_AsString: it returns a mutable char* pointing to the
contents of a byte instance.  This presents several obvious problems.  For
starters, it burdens a relocating garbage collector to pin objects or
create a temporary copy of an object's contents in non-moving memory.  It
also has implications for treating PyObejct* as a handle, using tagged
pointers (and tagged immediates), and multi-threading.

To eliminate C-API functions such as PyBytes_AsString, PyUnicode_AsUTF8,
etc., new functions should be added to the C-API that copy the contents of
objects out into a buffer, similar to PyUnicode_AsUCS4 or to return the
contents in an dynamically allocated buffer like PyUnicode_AsUCS4Copy.


On Mon, Jun 22, 2020 at 5:12 AM Victor Stinner  wrote:

> Hi,
>
> PEP available at: https://www.python.org/dev/peps/pep-0620/
>
> 
> This PEP is the result of 4 years of research work on the C API:
> https://pythoncapi.readthedocs.io/
>
> It's the third version. The first version (2017) proposed to add a
> "new C API" and advised C extensions maintainers to opt-in for it: it
> was basically the same idea as PEP 384 limited C API but in a
> different color. Well, I had no idea of what I was doing :-) The
> second version (April 2020) proposed to add a new Python runtime built
> from the same code base as the regular Python runtime but in a
> different build mode, the regular Python would continue to be fully
> compatible.
>
> I wrote the third version, the PEP 620, from scratch. It now gives an
> explicit and concrete list of incompatible C API changes, and has
> better motivation and rationale sections. The main PEP novelty is the
> new pythoncapi_compat.h header file distributed with Python to provide
> new C API functions to old Python versions, the second novelty is the
> process to reduce the number of broken C extensions.
>
> Whereas PEPs are usually implemented in a single Python version, the
> implementation of this PEP is expected to be done carefully over
> multiple Python versions. The PEP lists many changes which are already
> implemented in Python 3.7, 3.8 and 3.9. It defines a process to reduce
> the number of broken C extensions when introducing the incompatible C
> API changes listed in the PEP. The process dictates the rhythm of
> these changes.
> 
>
>
> PEP: 620
> Title: Hide implementation details from the C API
> Author: Victor Stinner 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 19-June-2020
> Python-Version: 3.10
>
> Abstract
> 
>
> Introduce C API incompatible changes to hide implementation details.
>
> Once most implementation details will be hidden, evolution of CPython
> internals would be less limited by C API backward compatibility issues.
> It will be way easier to add new features.
>
> It becomes possible to experiment with more advanced optimizations in
> CPython
> than just micro-optimizations, like tagged pointers.
>
> Define a process to reduce the number of broken C extensions.
>
> The implementation of this PEP is expected to be done carefully over
> multiple Python versions. It already started in Python 3.7 and most
> changes are already completed. The `Process to reduce the number of
> broken C extensions`_ dictates the rhythm.
>
>
> Motivation
> ==
>
> The C API blocks CPython evolutions
> ---
>
> Adding or removing members of C structures is causing multiple backward
> compatibility issues.
>
> Adding a new member breaks the stable ABI (PEP 384), especially for
> types declared statically (e.g. ``static PyTypeObject MyType =
> {...};``). In Python 3.4, the PEP 442 "Safe object finalization" added
> the ``tp_finalize`` member at the end of the ``PyTypeObject`` structure.
> For ABI backward compatibility, a new ``Py_TPFLAGS_HAVE_FINALIZE`` type
> flag was required to announce if the type structure contains the
> ``tp_finalize`` member. The flag was removed in Python 3.8 (`bpo-32388
> `_).
>
> The ``PyTypeObject.tp_print`` member, deprecated since Python 3.0
> released in 2009, has been removed in the Python 3.8 development cycle.
> But the change broke too many C extensions and had to be reverted before
> 3.8 final release. Finally, the member was removed again in Python 3.9.
>
> C extensions rely on the ability to access directly structure members,
> indirectly through the C API, or even directly. Modifying structures
> like ``PyListObject`` cannot be even considered.
>
> The ``PyTypeObject`` structure is the one which evolved the most, simply
> 

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Richard Damon]

On 6/25/20 6:48 PM, Emily Bowman wrote:
> On Thu, Jun 25, 2020 at 3:41 PM Richard Damon
> mailto:rich...@damon-family.org>> wrote:
> > Actually, you could make _ less special by still binding the value to
>
> it, just make it special in that you allow several values to be bound,
> and maybe just define that the result will be just one of the values,
> maybe even specify which if you want.
>
>
> Like Guido said above, the problem is that _ is already effectively
> reserved for translated text. Combining the two would feel a bit
> weird, but should still be possible.

I thought _ was also commonly used as:

first, -, last = (1, 2, 3)

as a generic don't care about assignment. I guess since the above will
create a local, so not overwrite a 'global' function _ for translations,
so the above usage works as long as that function (or whatever namespace
you are in) doesn't use _ for translations. As long as the bindings in
match also make the symbol a local (which seems reasonable) then you
would get a similar restriction.

-- 
Richard Damon
___
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/M5HWPDG43KGHKM6JVH7ZAGK6YT7OYVJR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Gregory P. Smith]

Litmus test: Give someone who does not know Python this code example from
the PEP and ask them what it does and why it does what it does:

match get_shape():
case Line(start := Point(x, y), end) if start == end:
print(f"Zero length line at {x}, {y}")

I expect confusion to be the result.  If they don't blindly assume the
variables come from somewhere not shown to stop their anguish.

With Python experience, my own reading is:
 * I see start actually being assigned.
 * I see nothing giving values to end, x, or y.
 * Line and Point are things being called, probably class constructions due
to being Capitalized.
 * But where did the parameter values come from and why and how can end be
referred to in a conditional when it doesn't exist yet?
   They appear to be magic!

Did get_shape() return these? (i think not).  Something magic and *implicit
rather than explicit* happens in later lines.  The opposite of what Python
is known for.

Where's the pseudo-code describing *exactly* what the above looks like
logically speaking? (there's a TODO in the PEP for the __match__ protocol
code so I assume it will come, thanks!).  I can guess _only_ after reading
a bunch of these discussions and bits of the PEP.  Is it this?  I can't
tell.

shape = get_shape()
values_or_none = Line.__match__(shape)
if values_or_none:
  start, end = values_or_none
  if start == end:
if x, y := Point.__match__(shape):
  print(...)
  del x, y
  else:
print(...)
  del start, end
else:
  # ... onto the next case: ?

Someone unfamiliar with Python wouldn't even have a chance of seeing that.
I had to rewrite the above many times, I'm probably still wrong.

That sample is very confusing code.  It makes me lean -1 on the PEP overall
today.

This syntax does not lead to readable logically understandable code.  I
wouldn't encourage anyone to write code that way because it is not
understandable to others.  We must never assume others are experts in the
language they are working on code in if we want it to be maintainable.  I
wouldn't approve a code review containing that example.

It would help *in part* if ()s were not used to invoke the __match__
protocol.  I think a couple others also mentioned this earlier.  Don't make
it look like a call.  Use different tokens than ().  Point{x, y} for
example.  Or some way to use another token unused in that context in our
toolbook such as @ to signify "get a matcher for this class" instead of
"construct this class".  for example ClassName@() as our match protocol
indicator, shown here with explicit assignments for clarity:

match get_shape() as shape:
  case start, end := Line@(shape):

no implicit assignments, it is clear where everything comes from.  it is
clear it isn't a constructor call.

downside?  possibly a painful bug when someone forgets to type the @.  but
the point of it not being construction needs to be made.  not using ()s but
instead using ClassName@{} or just ClassName{} would prevent that.

The more nested things get with sub-patterns, the worse the confusion
becomes.  The nesting sounds powerful but is frankly something I'd want to
forbid anyone from using when the assignment consequences are implicit.  So
why implement sub-patterns at all?  All I see right now is pain.

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

[Python-Dev] Re: Intended invariants for signals in CPython

[Yonatan Zunger via Python-Dev]

What, weird edge cases involving *signals?* Never! :)

Here's a nice simple one: it takes at least a few opcodes to set said
global flag, during which (depending on the whims of how eval_break gets
set) yet another signal might get raised and handled.

I did just make a post to python-ideas about the possibility of adding a
"sys.suppress_signals" method; it seems like it would be surprisingly easy
in CPython (basically by just adding another check at the start of
_PyErr_CheckSignalsTstate) but would also be a truly impressive footgun.
Not sure if I'm going to try to climb that particular mountain yet, but I
figured I'd see what obvious holes other people could poke in it.

Thanks for your help!

On Thu, Jun 25, 2020 at 1:27 PM Antoine Pitrou  wrote:

> On Thu, 25 Jun 2020 11:18:13 -0700
> Yonatan Zunger via Python-Dev  wrote:
> > Also, just to sanity-check that I understand things correctly: Python
> > signal handlers *are* reentrant, in that a signal handler can be
> > interrupted by another signal, is that right? Is there any general
> > recommendation on how to write signal handlers in order to manage that?
>
> To be honest, I've never thought about that.  If you need to care about
> reentrancy, you should perhaps use some kind of global flag to detect
> it (hopefully you won't run into weird edge cases...).
>
> > (Antoine, I *so* wish I could be doing less with signals and signal
> > handlers right now. Alas, I have a combination of a SIGTERM-happy runtime
> > environment and a long-story situation involving wacky multiprocessing to
> > avoid issues in someone else's C library that make that impossible. So
> > instead I'm trying to write a general library to help simplify the task,
> > and so thinking about a lot of slightly nutty corner cases...)
>
> Ha, I wisk you good luck with that :-)
>
> Best regards
>
> Antoine.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/KBD7XG5QPRQRP52FVPAFLZ3G6PSPPVYE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

Yonatan Zunger

Distinguished Engineer and Chief Ethics Officer

He / Him

zun...@humu.com

100 View St, Suite 101

Mountain View, CA 94041

Humu.com   · LinkedIn
  · Twitter

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

[Python-Dev] Re: The Anti-PEP

[Gregory P. Smith]

On Thu, Jun 25, 2020 at 6:49 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

> > it is hard to make a decision between the pros and cons,
> > when the pros are in a single formal document and the
> > cons are scattered across the internet.
>
> Mark, I support your idea.  It is natural for PEP authors to not fully
> articulate the voices of opposition or counter-proposals.
> The current process doesn't make it likely that a balanced document is
> created for decision making purposes.
>
>
On some PEPs in the past I seem to recall we've had the PEP author, or at
least editor after the initial draft kicked things off _not_ be among those
invested in seeing the PEP be approved.

Or maybe I'm conflating the old role of the PEP delegate with the editor?

Regardless i don't see how an anti-pep would work much better, but I also
don't see anything stopping anyone from trying one.  I worry that it'll
fragment conversation even more and separate discussions so that everyone
is even more confused about overall opinion tallies?  one way to find out...

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Gregory P. Smith]

On Wed, Jun 24, 2020 at 7:58 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Ethan Furman writes:
>
>  > _ does not bind to anything, but of what practical importance is that?
>
> *sigh* English speakers ... mutter ... mutter ... *long sigh*
>
> It's absolutely essential to the use of the identifier "_", otherwise
> the I18N community would riot in the streets of Pittsburgh.  Not good
> TV for Python (and if Python isn't the best TV, what good is it? ;-)
>
>
Can I use an i18n'd _("string") within a case without jumping through hoops
to assign it to a name before the match:?


> Steve
> ___
> 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/ENUPVNZEW7DFJKVCKK5XQ4NLV3KOW36C/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WPPCVM6YPAYSGA7AJ5YOKGLQQNGXFLF4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Intended invariants for signals in CPython

[Yonatan Zunger via Python-Dev]

HOLY CRAP THIS IS MADNESS. I kind of love it. :)

And it's related to some other problems that have been on my mind (how to
"paint" stack frames with user-defined variables, with those variables then
being used by things like CPU/heap profilers as smart annotations), and I
have to say it's a damned clever solution to the problem.

On Thu, Jun 25, 2020 at 6:35 PM Yonatan Zunger  wrote:

> I had not -- thank you!
>
> On Thu, Jun 25, 2020 at 1:49 PM Chris Jerdonek 
> wrote:
>
>> On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev <
>> python-dev@python.org> wrote:
>>
>>> That said, the meta-question still applies: Are there things which are
>>> generally intended *not* to be interruptible by signals, and if so, is
>>> there some consistent way of indicating this?
>>>
>>
>> Yonatan, Nathaniel Smith wrote an interesting post a few years ago that
>> includes some background about signal handling:
>> https://vorpus.org/blog/control-c-handling-in-python-and-trio/
>> Have you seen that?
>>
>> --Chris
>>
>>
>>>
>
> --
>
> Yonatan Zunger
>
> Distinguished Engineer and Chief Ethics Officer
>
> He / Him
>
> zun...@humu.com
>
> 100 View St, Suite 101
>
> Mountain View, CA 94041
>
> Humu.com   · LinkedIn
>   · Twitter
> 
>


-- 

Yonatan Zunger

Distinguished Engineer and Chief Ethics Officer

He / Him

zun...@humu.com

100 View St, Suite 101

Mountain View, CA 94041

Humu.com   · LinkedIn
  · Twitter

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Gregory P. Smith]

On Wed, Jun 24, 2020 at 7:34 PM Taine Zhao  wrote:

> > e.g., "or", and then I wonder "what does short-circuiting have to do
> > with it?". All reuse of symbols carries baggage.
>
> "or" brings an intuition of the execution order of pattern matching, just
> like how people already know about "short-circuiting".
>
> "or" 's operator precedence also suggests the syntax of OR patterns.
>
> As we have "|"  as an existing operator, it seems that there might be
> cases that the precedence of "|" is not consistent with it in an
> expression. This will mislead users.
>

I prefer "or" to "|" as a combining token as there is nothing bitwise going
on here.  "or" reads better.   Which is why Python used it for logic
operations in the first place.  It is simple English.  "|" does not read
like or to anyone but a C based language programmer.  Something Python
users should never need to know.

There is no existing pythonic way to write "evaluate all of these things at
once in no specific order".

And in reality, there will be an order. It'll be sequential, and if it
isn't the left to right order that things are written with the "|" between
them, it will break someones assumptions and make optimization harder.
Some too-clever-for-the-worlds-own-good author is going to implement
__match__ classmethods that have side effects and make state changes that
impact the behavior of later matcher calls (no sympathy for them). Someone
else is going to order them most likely to least likely for performance (we
should have sympathy for that).

Given we only propose to allow a single trailing guard if per case, using
"or" instead of "|" won't be confused with an if's guard condition.

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

[Python-Dev] Re: The Anti-PEP

[Raymond Hettinger]

> it is hard to make a decision between the pros and cons, 
> when the pros are in a single formal document and the 
> cons are scattered across the internet.

Mark, I support your idea.  It is natural for PEP authors to not fully 
articulate the voices of opposition or counter-proposals.   
The current process doesn't make it likely that a balanced document is created 
for decision making purposes.


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

[Python-Dev] Re: Intended invariants for signals in CPython

[Yonatan Zunger via Python-Dev]

I had not -- thank you!

On Thu, Jun 25, 2020 at 1:49 PM Chris Jerdonek 
wrote:

> On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev <
> python-dev@python.org> wrote:
>
>> That said, the meta-question still applies: Are there things which are
>> generally intended *not* to be interruptible by signals, and if so, is
>> there some consistent way of indicating this?
>>
>
> Yonatan, Nathaniel Smith wrote an interesting post a few years ago that
> includes some background about signal handling:
> https://vorpus.org/blog/control-c-handling-in-python-and-trio/
> Have you seen that?
>
> --Chris
>
>
>>

-- 

Yonatan Zunger

Distinguished Engineer and Chief Ethics Officer

He / Him

zun...@humu.com

100 View St, Suite 101

Mountain View, CA 94041

Humu.com   · LinkedIn
  · Twitter

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

[Python-Dev] Re: The Anti-PEP

[Stephen J. Turnbull]

Brett Cannon writes:

 > I agree, and that's what the Rejected Ideas section is supposed to
 > capture.

Perhaps there could be guidance, in documentation (and if appropriate
from the PEP-Delegate or the Steering Council), that the PEP proponent
collaborate with a leading opponent, critic, and/or undecided party on
the Rejected Ideas section?  It shouldn't be presented as a big deal
for fairness (PEPs are supposed to be advocacy documents), but rather
offloading some of the work on an interested party whose specific
interest is in the opposition side of the discussion.  Thus it would
contribute to a more complete summary of the discussion.

As long as I'm here, -1 on Anti-PEPs as such.  I agree with the
reasons given by others.  I also feel that although Rationale and
Rejected Ideas sections tend to be extremely compressed compared to
the mailing list discussions, they usually do reflect the essentials
of those discussions.  At least in cases where I personally felt the
PEPs were questionable ideas at the time.[1]

In particular, IMO Rationale need not rebut every objection, but must
present a *sufficient* case for implementation, including overcoming
concrete objections (specific design flaws and the like).  In cases
where the go-no-go decision came down to the wire, the PEP-Delegate
and Steering Council should ensure that the Rationale section should
reflect their concerns about balancing interests as well.

Steve

Footnotes: 
[1]  The fact is that I'm more likely to carefully read a PEP that I
find questionable than one that I agree with from the get-go.  YMMV.
___
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/YBEPAG6GUOY7E5FF7O2FJP2SA6OPXPMP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Paul Svensson]

On Thu, 25 Jun 2020, Richard Damon wrote:


On 6/25/20 10:42 AM, Greg Ewing wrote:

On 26/06/20 1:18 am, Rhodri James wrote:

I will quickly and regularly forget that in this one place, "_" is
special.


You don't have to remember that it's special to understand what
'case _' does. Even if it were treated as an ordinary name, it
would still have the effect of matching anything.


Actually, you could make _ less special by still binding the value to
it, just make it special in that you allow several values to be bound,
and maybe just define that the result will be just one of the values,
maybe even specify which if you want.


We already allow (x, x) = (1, 2)
So, why do we need to disallow binding several values to the same name ?
Without the restriction, there's no need for _ to be special,
and anyone using _ for something else, can use some other dummy for matching.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Greg Ewing]

On 26/06/20 5:07 am, MRAB wrote:
How do you indicate that you want it to match anything and don't care 
about the value?


   case Spam(-> _):

Or if that's considered too verbose and we're willing to make
_ even more special, it could be just

   case Spam(_):

In that case we would be regarding _ as a "value that matches
anything" rather than a "name that doesn't get assigned 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/3YJCAGV56FNCGT3VLTJUOHIIIROZR3IY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Brandt Bucher]

Ethan Furman wrote:
> Ouch.  That seems like a pretty serious drawback.  Will this issue be 
> resolved?

It's currently being revisited.

Realistically, I'd imagine that we either find some straightforward way of 
opting-in to the current default behavior (allowing one arg to be positionally 
matched against the proxy), or lose the nice behavior altogether. Obviously the 
former is preferable, since it's not trivial to reimplement yourself.
___
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/UZ77WPWH4DK3IK3ANKQYOCXKVW4AERIE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Ethan Furman]

In this example code from the PEP:

match shape:
case Point(x, y):
...
case Rectangle(x0, y0, x1, y1, painted=True):

What is the "painted=True" portion doing?  Is it requiring that the painted 
attribute of the shape object be True in order to match?

--
~Ethan~
___
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/G2TQXL5WZBTDKA2OLZ2WYLDN5F5AK2G5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Ethan Furman]

On 06/25/2020 04:07 PM, Brandt Bucher wrote:

Pablo Galindo Salgado wrote:

...users can do a positional match against the proxy with a name pattern:

match input:
 case datetime.date(dt):
 print(f"The date {dt.isoformat()}"

...if 'datetime.date' were updated to implement a non-default __match_args__, 
allowing individual fields to be pulled out of it like this, then the first 
block would be valid, correct code before the change, but would raise an 
ImpossibleMatch after the change because 'dt' is not a field in __match_args__. 
Is this argument misinterpreting something about the PEP or is missing some 
important detail?


Well yeah, it's actually a fair bit worse than you describe. Since dt is matched 
positionally, it wouldn't raise during matching - it would just succeed as before, but 
instead binding the year attribute (not the whole object) to the name "dt". So 
it wouldn't fail until later, when your method call raises a TypeError.


Ouch.  That seems like a pretty serious drawback.  Will this issue be resolved?

--
~Ethan~
___
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/SD44QMJPUFXQGJW2VSB23RNQGKKYZDOO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Brandt Bucher]

Pablo Galindo Salgado wrote:
> ...users can do a positional match against the proxy with a name pattern:
>
> match input:
> case datetime.date(dt):
> print(f"The date {dt.isoformat()}"
>
> ...if 'datetime.date' were updated to implement a non-default __match_args__, 
> allowing individual fields to be pulled out of it like this, then the first 
> block would be valid, correct code before the change, but would raise an 
> ImpossibleMatch after the change because 'dt' is not a field in 
> __match_args__. Is this argument misinterpreting something about the PEP or 
> is missing some important detail?

Well yeah, it's actually a fair bit worse than you describe. Since dt is 
matched positionally, it wouldn't raise during matching - it would just succeed 
as before, but instead binding the year attribute (not the whole object) to the 
name "dt". So it wouldn't fail until later, when your method call raises a 
TypeError.
___
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/Y7DJJA2ONIRJSMMA6PYKAYCZSYIECY4D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Thu, Jun 25, 2020 at 3:41 PM Richard Damon 
wrote:
> Actually, you could make _ less special by still binding the value to

> it, just make it special in that you allow several values to be bound,
> and maybe just define that the result will be just one of the values,
> maybe even specify which if you want.
>

Like Guido said above, the problem is that _ is already effectively
reserved for translated text. Combining the two would feel a bit weird, but
should still be possible.
___
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/KJMYK6AP3CPA2LJUFSAKKO3JSHZJYZCP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Emily Bowman]

On Wed, Jun 24, 2020 at 12:46 PM Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>

I don't think combining assignment and wildcard will help. '_' is fine for
that. I could get used to '?' as an assignment or a wildcard, but it would
always be a double-take if it was both.

I've seen languages that use '>foo' to indicate assignment, but I can't for
the life of me remember which now, aside from shell redirection. '=foo'
might be more obvious. In the end I think it's only important that there's
some assignment operator, and we'll all get used to whatever you choose.
___
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/QSJRX2QAPA45KMJOZHW2WYPJWRPRFL65/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Richard Damon]

On 6/25/20 10:42 AM, Greg Ewing wrote:
> On 26/06/20 1:18 am, Rhodri James wrote:
>> I will quickly and regularly forget that in this one place, "_" is
>> special.
>
> You don't have to remember that it's special to understand what
> 'case _' does. Even if it were treated as an ordinary name, it
> would still have the effect of matching anything.
>
Actually, you could make _ less special by still binding the value to
it, just make it special in that you allow several values to be bound,
and maybe just define that the result will be just one of the values,
maybe even specify which if you want.

-- 
Richard Damon
___
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/EIPWQ6W3CGNV5GGRDCCQ3M63CQFMYDM5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Thu, Jun 25, 2020 at 9:21 AM Rhodri James  wrote:

> Well, now is the time for expressing surprise :-p
>
> As I've said before, one of my main problems with the PEP is as you go
> through it, more and more special cases and surprises appear, and the
> consequences of earlier surprises generate more special cases and
> surprises.  You claim not unreasonably that it's easy to remember that
> "_" is special in matches.  Maybe you're right, but that decision has
> consequences spelled out later in the PEP that are less easy to
> remember.  Another example: I had not previously thought the definition
> of name patterns to be surprising, but apparently they are (it just
> surprised me, at any rate).  That consequently makes the definition of
> constant value patterns, which I was already iffy about, really quite
> surprising.
>
> Each individual learning curve might be small, but cumulative total by
> the time you reach the end of the PEP is large.  Simple match statements
> will, with adequate squinting, look recognisably like other areas of
> Python.  Complex match statements won't.  And that's a problem for
> anyone who wants to be able to read someone else's code.
>
> Bear in mind I am predominantly a C programmer who uses Python from time
> to time for tools and glue.  If I have to put in effort to learn new
> special-case rules in Python, that's an active discouragement; I'm
> frankly unlikely to bother, and more likely to write those tools and
> glue in C instead.  I'm certainly much less likely to use someone else's
> tools and glue if I have to re-read the spec to remind myself what all
> the gotchas are.
>

On my personal "potentially inscrutable uses of a tool" this still rates
well below list comprehensions, so there's that; the biggest pet peeve I
have anymore is understanding at a glance what is and isn't an assignment.
This is a draft PEP and a lot of discussion around making assignment vs
matched classes more explicit, so it's not like this is going to be set in
stone, and I doubt that most will ever use the more esoteric parts of the
syntax. One way or another, this is going to be a far more capable, and
thus complex, tool than a switch statement, so there's only so much
obviousness you can ask for coming in blind.
___
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/FIPQMOHWVYOPBFLH2MZN66Z2DM7TBWL7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Intended invariants for signals in CPython

[Chris Jerdonek]

On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev <
python-dev@python.org> wrote:

> That said, the meta-question still applies: Are there things which are
> generally intended *not* to be interruptible by signals, and if so, is
> there some consistent way of indicating this?
>

Yonatan, Nathaniel Smith wrote an interesting post a few years ago that
includes some background about signal handling:
https://vorpus.org/blog/control-c-handling-in-python-and-trio/
Have you seen that?

--Chris


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

[Python-Dev] Re: The Anti-PEP

[Chris Jerdonek]

On Thu, Jun 25, 2020 at 11:52 AM Brett Cannon  wrote:

> On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou 
> wrote:
>
>> I don't think this really works.  A PEP has to present a consistent
>> view of the world, and works as a cohesive whole.  Arguments against a
>> PEP don't form a PEP in themselves, they don't need to be consistent
>> with each other; they merely oppose a particular set of propositions.
>> So an "anti-PEP" would not be anything like a PEP; it would just be a
>> list of assorted arguments.
>>
>
> I agree, and that's what the Rejected Ideas section is supposed to capture.
>

When I read the description of Rejected Ideas in PEP 1, it seems like it's
more for ideas that have been rejected that are still in line with the
overall PEP / motivation. It seems like what Mark is suggesting would fit
better in a separate "Arguments Against" section. I guess it would be
possible to include "reject the PEP" as a rejected idea or each individual
argument against as its own rejected "idea," but it would seem a little
weird to me to organize it that way.

I do see that PEP 1 says about the Rationale section:

The rationale should provide evidence of consensus within the community and
> discuss important objections or concerns raised during discussion.


But what Mark is suggesting might be too large for the Rationale section.

--Chris


> If a PEP is not keeping a record of what is discussed, including opposing
> views which the PEP is choosing not to accept, then that's a deficiency in
> the PEP and should be fixed. And if people feel their opposing view was not
> recorded properly, then that should be brought up.
>
>
___
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/NJRZ4SZ4RYQIXJHGIOS5UD2XT4RAIFH5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Intended invariants for signals in CPython

[Antoine Pitrou]

On Thu, 25 Jun 2020 11:18:13 -0700
Yonatan Zunger via Python-Dev  wrote:
> Also, just to sanity-check that I understand things correctly: Python
> signal handlers *are* reentrant, in that a signal handler can be
> interrupted by another signal, is that right? Is there any general
> recommendation on how to write signal handlers in order to manage that?

To be honest, I've never thought about that.  If you need to care about
reentrancy, you should perhaps use some kind of global flag to detect
it (hopefully you won't run into weird edge cases...).

> (Antoine, I *so* wish I could be doing less with signals and signal
> handlers right now. Alas, I have a combination of a SIGTERM-happy runtime
> environment and a long-story situation involving wacky multiprocessing to
> avoid issues in someone else's C library that make that impossible. So
> instead I'm trying to write a general library to help simplify the task,
> and so thinking about a lot of slightly nutty corner cases...)

Ha, I wisk you good luck with that :-)

Best regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KBD7XG5QPRQRP52FVPAFLZ3G6PSPPVYE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Brett Cannon]

On Thu, Jun 25, 2020 at 3:17 AM Greg Ewing 
wrote:

> On 25/06/20 7:50 pm, Anders Munch wrote:
> > Pascal is a precedent for this placement of 'case',
>
> Yes, but it doesn't use it with "match". In fact it doesn't have
> any keyword in front of the values to be matched; it goes like
>
> case n of
>1: ...;
>2: ...;
>3: ...;
> end
>
> If we did that in Python it would look like this:
>
> case shape:
>Point(x, y):
>   ...
>Line(x1, y1, x2, y2):
>   ...
>Circle(cx, cy, r):
>   ...
>
> What think folks of this?
>

It feels like it would be the only bit of syntax in Python that requires a
`:` and yet has no keyword to go with it for clarification of what the
block is meant for. That makes me not like this.
___
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/BUGY5NJEZR5BWGHE2LXNB4UJ5C2TJY5O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[Brett Cannon]

On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou  wrote:

> On Thu, 25 Jun 2020 11:57:49 +0100
> Mark Shannon  wrote:
> >
> > An Anti-PEP is a way to ensure that those opposed to a PEP can be heard
> > and, if possible, have a coherent voice.
> > Hopefully, it would also make things a lot less stressful for PEP
> authors.
>
> I don't think this really works.  A PEP has to present a consistent
> view of the world, and works as a cohesive whole.  Arguments against a
> PEP don't form a PEP in themselves, they don't need to be consistent
> with each other; they merely oppose a particular set of propositions.
> So an "anti-PEP" would not be anything like a PEP; it would just be a
> list of assorted arguments.
>

I agree, and that's what the Rejected Ideas section is supposed to capture.
If a PEP is not keeping a record of what is discussed, including opposing
views which the PEP is choosing not to accept, then that's a deficiency in
the PEP and should be fixed. And if people feel their opposing view was not
recorded properly, then that should be brought up.

Otherwise in my view the only time an opposing PEP should be written is if
it's actually proposing an alternative solution, not to simply refute a PEP
to not be accepted.
___
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/V4IPZWFVJDHFN6K77VMHYCIOKQFGI43A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Ethan Furman]

On 06/25/2020 03:00 AM, Greg Ewing wrote:

On 25/06/20 7:50 pm, Anders Munch wrote:



Pascal is a precedent for this placement of 'case',


Yes, but it doesn't use it with "match". In fact it doesn't have
any keyword in front of the values to be matched; it goes like

    case n of
   1: ...;
   2: ...;
   3: ...;
    end

If we did that in Python it would look like this:

    case shape:
   Point(x, y):
  ...
   Line(x1, y1, x2, y2):
  ...
   Circle(cx, cy, r):
  ...


I strongly prefer "match expression: case ...:"

--
~Ethan~
___
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/OZ6GSBPCDOJW73DAPXTGVW2L6OQLRIGH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Pablo Galindo Salgado]

I was talking with a colleague today about the PEP and he raised a couple
of question regarding the match protocol and the proxy result.

One question is that taking into account that 'case object(x)' is valid for
every object, but it does (could do) something different for objects
that have a non-None __match_args__ it seems that implementing
__match_args__ will break Liskov substitutability as you could not
substitute
the child in a context where you expect a parent.

Even if you don't care about Liskov substitutability seems that introducing
a __match_args__ for a class will almost always be backwards
incompatible. For example, let's say that 'datetime.date' doesn't have a
custom matching defined, so it inherits the default object.__match__,
 which does:

class object:
@classmethod
def __match__(cls, instance):
if isinstance(instance, cls):
return instance

The PEP notes that:
> The above implementation means that by default only match-by-name and a
single positional match by value against the proxy will work

Which means that users can do a positional match against the proxy with a
name pattern:

match input:
case datetime.date(dt):
print(f"The date {dt.isoformat()}"

Imagine that later, someone notices that it would be reasonable to support
structural pattern matching for the fields of a 'datetime.date' so that
users could do:

match birthday:
case datetime.date(year) if year == 1970:
print("You were born in 1970")

But, if 'datetime.date' were updated to implement a non-default
__match_args__, allowing individual fields to be pulled out of it like
this, then the first block would be valid,
correct code before the change, but would raise an ImpossibleMatch after
the change because 'dt' is not a field in __match_args__.

Is this argument misinterpreting something about the PEP or is missing some
important detail?

On Wed, 24 Jun 2020 at 20:47, Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T32GEZA43AE6LDSAG35I3F2ITXJ5SPTJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Intended invariants for signals in CPython

[Yonatan Zunger via Python-Dev]

Also, just to sanity-check that I understand things correctly: Python
signal handlers *are* reentrant, in that a signal handler can be
interrupted by another signal, is that right? Is there any general
recommendation on how to write signal handlers in order to manage that?

(Antoine, I *so* wish I could be doing less with signals and signal
handlers right now. Alas, I have a combination of a SIGTERM-happy runtime
environment and a long-story situation involving wacky multiprocessing to
avoid issues in someone else's C library that make that impossible. So
instead I'm trying to write a general library to help simplify the task,
and so thinking about a lot of slightly nutty corner cases...)

On Thu, Jun 25, 2020 at 10:33 AM Yonatan Zunger  wrote:

> I'm taking it from this thread that suppressing signals in a small window
> is not something anyone in their right mind would really want to attempt.
> :) (Or that if they did, it would have to be through a proper change to the
> runtime, not something higher-level)
>
> On Thu, Jun 25, 2020 at 7:14 AM Antoine Pitrou  wrote:
>
>>
>> Le 25/06/2020 à 16:00, Guido van Rossum a écrit :
>> > On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou > > > wrote:
>> >
>> > ...  The intent, though, is that any function
>> > waiting on an external event (this can be a timer, a socket, a
>> > lock, a directory...) should be interruptible so that Ctrl-C works
>> in
>> > an interactive prompt.
>> >
>> > That’s not really true though right? Locks can block the REPL.
>>
>> On POSIX they don't.  On Windows it's a long-standing bug:
>> https://bugs.python.org/issue29971
>>
>> Regards
>>
>> Antoine.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/4TNEA5KNWCYTJVIPISUZKVXVDK2BQJWT/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
>
> Yonatan Zunger
>
> Distinguished Engineer and Chief Ethics Officer
>
> He / Him
>
> zun...@humu.com
>
> 100 View St, Suite 101
>
> Mountain View, CA 94041
>
> Humu.com   · LinkedIn
>   · Twitter
> 
>


-- 

Yonatan Zunger

Distinguished Engineer and Chief Ethics Officer

He / Him

zun...@humu.com

100 View St, Suite 101

Mountain View, CA 94041

Humu.com   · LinkedIn
  · Twitter

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Gregory P. Smith]

On Wed, Jun 24, 2020 at 1:38 PM Luciano Ramalho  wrote:

> Thank you Guido, Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin
> for this fun and very useful new feature.
>
> I do enjoy pattern matching a lot in Elixir—my favorite language these
> days, after Python.
>
> I don't want to start a discussion, but I just want to say that as an
> instructor I fear this core language addition may make the language
> less approachable to the non-IT professionals, researchers etc. who
> have saved Python from the decline that we can observe happening in
> Ruby—a language of similar age, with similar strengths and weaknesses,
> but never widely adopted outside of the IT profession.
>
> After I wrap up Fluent Python 2e (which is aimed at professional
> developers) I hope I can find the time to tackle the challenge of
> creating introductory Python content that manages to explain pattern
> matching and other recent developments in a way that is accessible to
> all.
>

Hold on a while.  This feature does not exist.  This PEP has not been
accepted.  Don't count your chickens.py before they hatch.

The last P in PEP stands for Proposal for a reason.  Rejection is a
perfectly valid option.  As is a significant reworking of the proposal so
that it doesn't turn into a nightmare.  This one needs a lot of work at a
minimum.  As proposed, it is extremely non-approachable and non-trivial.

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

[Python-Dev] Re: Intended invariants for signals in CPython

[Yonatan Zunger via Python-Dev]

I'm taking it from this thread that suppressing signals in a small window
is not something anyone in their right mind would really want to attempt.
:) (Or that if they did, it would have to be through a proper change to the
runtime, not something higher-level)

On Thu, Jun 25, 2020 at 7:14 AM Antoine Pitrou  wrote:

>
> Le 25/06/2020 à 16:00, Guido van Rossum a écrit :
> > On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou  > > wrote:
> >
> > ...  The intent, though, is that any function
> > waiting on an external event (this can be a timer, a socket, a
> > lock, a directory...) should be interruptible so that Ctrl-C works in
> > an interactive prompt.
> >
> > That’s not really true though right? Locks can block the REPL.
>
> On POSIX they don't.  On Windows it's a long-standing bug:
> https://bugs.python.org/issue29971
>
> Regards
>
> Antoine.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4TNEA5KNWCYTJVIPISUZKVXVDK2BQJWT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

Yonatan Zunger

Distinguished Engineer and Chief Ethics Officer

He / Him

zun...@humu.com

100 View St, Suite 101

Mountain View, CA 94041

Humu.com   · LinkedIn
  · Twitter

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-25 08:50, Anders Munch wrote:

Eric Nieuwland :

I have some doubt about the keyword

Guido van Rossum [mailto:gu...@python.org]:

Many people have tried to come up with a different keyword here, but nothing
has been found that comes even close to the simplicity of match. Plus, several
other languages (Scala, Rust) use it too (which is further evidence that it's
a natural fit).
  
I was thinking that 'match' and 'case' are reversed: The top line presents the

_case_ to be studied.  The patterns that follow try to _match_ the presented 
case.

Trying it out on PEP example:

case input:
 match x if x > MAX_INT:
 print("Got a large number")

I think it reads well, in particular when like here there's a condition
attached.  The second line is almost English: "match x if x greater than max
int".

Pascal is a precedent for this placement of 'case', although of course Niklaus
Wirth is not a native English speaker either.

Some languages use 'case' at the start of the construct; other languages 
use 'case' for the individual values. There are precedents for both 
placements.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[MRAB]

On 2020-06-25 04:54, Greg Ewing wrote:

I had another thought about a way to make the bound names explicit.

 # Keyword
 case Point(x -> px, y -> py):

 # Positional
 case Point(-> x, -> y):

 # Sub-pattern, positional
 case Line(Point() -> p1, Point() -> p2):

 # Sub-pattern, keyword
 case Line(start: Point() -> p1, end: Point() -> p2):

How do you indicate that you want it to match anything and don't care 
about the value?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Rhodri James]

On 25/06/2020 16:48, Tim Peters wrote:

[Tim]

See reply to Glenn. Can you give an example of a dotted name that is
not a constant value pattern? An example of a non-dotted name that is?
If you can't do either (and I cannot)), then that's simply what "if


  [Rhodri James ]

 case long.chain.of.attributes:


[Tim]

That's a dotted name and so is a constant value pattern - read the PEP.

  Every dotted name in a pattern is looked up using normal Python
  name resolution rules, and the value is used for comparison by
  equality with the matching expression (same as for literals).


[Rhodri]

Then I am surprised, which is worse.  "long.chain.of.attributes" looks
like an assignment target, and I would have expected the case to have
been a name pattern.


As always, I don't care whether something is obvious at first glance.
I care whether something can be learned with reasonable effort, and
"sticks" _after_ it's learned.  There's essentially nothing truly
obvious about programming.

This, from the PEP, is the entire grammar for a "name pattern'"

 name_pattern: NAME !('.' | '(' | '=')

That's it.  A plain name not followed by a dot, left paren, or equality sign.

While it may or may not surprise any given person at first glance,
it's very simple.  Put a fraction of the effort into learning it as
you're willing to expend on articulating surprise, and it would
already be far behind you ;-)


Well, now is the time for expressing surprise :-p

As I've said before, one of my main problems with the PEP is as you go 
through it, more and more special cases and surprises appear, and the 
consequences of earlier surprises generate more special cases and 
surprises.  You claim not unreasonably that it's easy to remember that 
"_" is special in matches.  Maybe you're right, but that decision has 
consequences spelled out later in the PEP that are less easy to 
remember.  Another example: I had not previously thought the definition 
of name patterns to be surprising, but apparently they are (it just 
surprised me, at any rate).  That consequently makes the definition of 
constant value patterns, which I was already iffy about, really quite 
surprising.


Each individual learning curve might be small, but cumulative total by 
the time you reach the end of the PEP is large.  Simple match statements 
will, with adequate squinting, look recognisably like other areas of 
Python.  Complex match statements won't.  And that's a problem for 
anyone who wants to be able to read someone else's code.


Bear in mind I am predominantly a C programmer who uses Python from time 
to time for tools and glue.  If I have to put in effort to learn new 
special-case rules in Python, that's an active discouragement; I'm 
frankly unlikely to bother, and more likely to write those tools and 
glue in C instead.  I'm certainly much less likely to use someone else's 
tools and glue if I have to re-read the spec to remind myself what all 
the gotchas are.


--
Rhodri James *-* Kynesim Ltd
___
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/5KCFYS3FEXQV65VJUX33IJI57OTXEMEV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Tim Peters]

[Tim]
 See reply to Glenn. Can you give an example of a dotted name that is
 not a constant value pattern? An example of a non-dotted name that is?
 If you can't do either (and I cannot)), then that's simply what "if

 [Rhodri James ]
>>> case long.chain.of.attributes:

[Tim]
>> That's a dotted name and so is a constant value pattern - read the PEP.
>>
>>  Every dotted name in a pattern is looked up using normal Python
>>  name resolution rules, and the value is used for comparison by
>>  equality with the matching expression (same as for literals).

[Rhodri]
> Then I am surprised, which is worse.  "long.chain.of.attributes" looks
> like an assignment target, and I would have expected the case to have
> been a name pattern.

As always, I don't care whether something is obvious at first glance.
I care whether something can be learned with reasonable effort, and
"sticks" _after_ it's learned.  There's essentially nothing truly
obvious about programming.

This, from the PEP, is the entire grammar for a "name pattern'"

name_pattern: NAME !('.' | '(' | '=')

That's it.  A plain name not followed by a dot, left paren, or equality sign.

While it may or may not surprise any given person at first glance,
it's very simple.  Put a fraction of the effort into learning it as
you're willing to expend on articulating surprise, and it would
already be far behind you ;-)
___
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/HQHVWUA7TSDOOGJTK4CO32CS3TRHEMW6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Rhodri James]

On 25/06/2020 15:42, Greg Ewing wrote:

On 26/06/20 1:18 am, Rhodri James wrote:
I will quickly and regularly forget that in this one place, "_" is 
special.


You don't have to remember that it's special to understand what
'case _' does. Even if it were treated as an ordinary name, it
would still have the effect of matching anything.


Maybe.  It's still ugly.

--
Rhodri James *-* Kynesim Ltd
___
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/OJQDY6VFNDZVNO6GZRGNSGX4BPQNVT4M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Rhodri James]

On 25/06/2020 15:40, Tim Peters wrote:

[Rhodri James ]

See reply to Glenn. Can you give an example of a dotted name that is
not a constant value pattern? An example of a non-dotted name that is?
If you can't do either (and I cannot)), then that's simply what "if



case long.chain.of.attributes:


That's a dotted name and so is a constant value pattern - read the PEP.

 Every dotted name in a pattern is looked up using normal Python
 name resolution rules, and the value is used for comparison by
 equality with the matching expression (same as for literals).


Then I am surprised, which is worse.  "long.chain.of.attributes" looks 
like an assignment target, and I would have expected the case to have 
been a name pattern.


--
Rhodri James *-* Kynesim Ltd
___
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/HKW7XZTN6JAYGMM7BQBKKC7M5OH6SARG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Russell Davis]

> '?foo' or 'foo?' to mark a variable binding

I like that idea a lot, with a strong inclination for the '?foo' variant.
Seeing the '?' first makes it clear right away that it's a special context.
And it keeps it more distinct from the None-aware operators (from PEP 505,
in case that gets adopted).
___
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/OOE4GZH4YLN6F7V2CK7ZHOW7NU3WY4E6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Evpok Padding]

On Thu, 25 Jun 2020, 16:48 Eric Nieuwland,  wrote:

> And maybe also an additional operator:
>
> if X matches Y:
> Z
>

This is really different from the PEP, but I like it, it reminds me of the
if let matching in Rust.
___
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/BYFWIUTEL33HU5ASAI5ZOQCS7PIVSEYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Greg Ewing]

On 26/06/20 1:18 am, Rhodri James wrote:
I will quickly and 
regularly forget that in this one place, "_" is special.


You don't have to remember that it's special to understand what
'case _' does. Even if it were treated as an ordinary name, it
would still have the effect of matching anything.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Eric Nieuwland]

Guido van Rossum wrote:

> Eric Nieuwland wrote:
> 
>> I have some doubt about the keyword: ‘match' seems to be at odds with
>> 'for', 'while', 'with', 'if' as it is more of an action.
>> It's more like 'try' but that statement has a completely different
>> structure.
> 
> Well, 'try' is also an action. :-) Many people have tried to come up with a
> different keyword here, but nothing has been found that comes even close to
> the simplicity of match. Plus, several other languages (Scala, Rust) use it
> too (which is further evidence that it's a natural fit).

It may also be evidence for not being able to come up with a more accurate 
keyword.

Reading through the PEP once more I noticed I was understanding

match X:
case Y:
Z

as

when X:
matches Y:
Z

which also to me seems to reflect the close relation to an if-elif-elif… 
construction.

This would almost naturally imply the possibility of:

when X:
matches Y:
Z
...
else:
Q

And maybe also an additional operator:

if X matches Y:
Z


>> Not a native speaker I don't have a reasonable alternative, though.
> 
> Me neither, but I speak it quite fluently now, and 'match' really feels
> like it fits well here.

Trying ;-)___
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/MN3TP6UL2QUO6VYIEPUGDGLIREZHYLI2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Tim Peters]

[Rhodri James ]
> I'm seriously going to maintain that I will forget the meaning of "case
> _:" quickly and regularly,

Actually,  you won't - trust me ;-)

> just as I quickly and regularly forget to use
> "|" instead of "+" for set union.  More accurately, I will quickly and
> regularly forget that in this one place, "_" is special.

Because that's the opposite of "accurate". There's nothing special
about "_" "in this one place". It's but a single application of that
"_" is used as a wildcard in _all_ matching contexts throughout the
PEP.

And it's not even new with this PEP.  "_" is routinely used already in
lots of code to mean "the syntax requires a binding target here, but I
don't care about the binding", from

lists = [[] for _ in range(100)]

to

first, _, third = triple

The last is especially relevant, because that's already a form of destructuring.

The only thing new about this use of "_" in the PEP is that it
specifies no binding will occur. Binding does occur in the examples
above (because there's nothing AT ALL special about "_" now - it's
just a one-character identifier, and all the rest is convention,
including that the REPL uses it to store the value of the
last-displayed object).


>> See reply to Glenn. Can you give an example of a dotted name that is
>> not a constant value pattern? An example of a non-dotted name that is?
>> If you can't do either (and I cannot)), then that's simply what "if

>case long.chain.of.attributes:

That's a dotted name and so is a constant value pattern - read the PEP.

Every dotted name in a pattern is looked up using normal Python
name resolution rules, and the value is used for comparison by
equality with the matching expression (same as for literals).


> or more likely
>
>case (foo.x, foo.y)

Ditto.

> for the first.  For the second, it's a no-brainer that you can't have a
> non-dotted name as a constant value pattern, since the current constant
> value pattern mandates a leading dot.

Not so.  _Solme_ dot is necessary and sufficient to identify a
constant value pattern now.  A leading dot is only _required_ in case
an intended constant value pattern would have no dots otherwise.
___
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/VDDYNQO7JOEZ2ENSHWIJAYBGXAHLBVLI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[Victor Stinner]

In my experience, different people keep proposing the same idea until
it's recorded in the PEP. The PEP doesn't have to address all remarks
or take in account all ideas, but it's good to record the most common
proposed ideas. The important part is to show that other people's
opinions have been heard.

If you want to have a clear summary of email discussions, maybe a wiki
page could be created somewhere. A PEP is usually authored by less
than 5 people. Collaborating on editing an anti-PEP doesn't sound
trivial. A wiki may better fit your use case, no?

Victor

Le jeu. 25 juin 2020 à 13:03, Mark Shannon  a écrit :
>
> Hi,
>
> I'd like to propose the "Anti-PEP".
>
> As I'm sure you've all noticed, contentious PEPs like 572, and now 622,
> generate a lot of email discussion.
> It's easy to feel that people's opinions are being dismissed and that
> legitimate criticisms aren't being heard.
> Conversely, PEP authors may feel they are being bombarded with
> criticism, which can be overwhelming.
>
> The acceptance, or rejection, of a PEP should be a cool technical
> decision. Whilst there may be considerations of aesthetics and usability
> that make it difficult to objective, the goal should be to choose what
> is best for the language in the long term.
>
> When deciding on PEP 484, I had to decide between a formally written PEP
> on one hand, and a mass of emails and informal polls I had done at
> conferences, on the other.
> I hope I made the right decision.
>
> Whether the ultimate decision is made by the steering committee or by a
> PEP delegate, it is hard to make a decision between the pros and cons,
> when the pros are in a single formal document and the cons are scattered
> across the internet.
>
> An Anti-PEP is a way to ensure that those opposed to a PEP can be heard
> and, if possible, have a coherent voice.
> Hopefully, it would also make things a lot less stressful for PEP authors.
>
>
> The Anti-PEP
> 
>
> The Anti-PEP is a single document that describes why a particular PEP
> should be rejected.
>
> An Anti-PEP is not a counter PEP. A counter PEP suggests an alternative
> solution to the same problem and will often share the same motivation as
> the original PEP. An Anti-PEP would usually reject the motivation or
> rationale, either as insufficient or as incorrect.
>
> An example of a counter PEP is 576, which was a counter to 575. The
> motivation was the same, but means proposed was quite different. As a
> result of the ensuing to and fro, we ended up with PEP 590, which was a
> clear improvement.
>
> I don't have an example of an Anti-PEP.
>
> We could start with PEP 611, https://www.python.org/dev/peps/pep-0611/.
> There were many criticisms of it on this mailing list, and I can promise
> the PEP author won't be upset by an Anti-PEP :)
> Anyone care to volunteer?
>
> Cheers,
> Mark.
> ___
> 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/JVKWNZEDRXR2IF3KM2JNUF6WT7WETUVK/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/4ZYLXIU5QXMLFYOQ5MSQBAA2YO555L3J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Intended invariants for signals in CPython

[Antoine Pitrou]

Le 25/06/2020 à 16:00, Guido van Rossum a écrit :
> On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou  > wrote:
> 
> ...  The intent, though, is that any function
> waiting on an external event (this can be a timer, a socket, a
> lock, a directory...) should be interruptible so that Ctrl-C works in
> an interactive prompt.
> 
> That’s not really true though right? Locks can block the REPL.

On POSIX they don't.  On Windows it's a long-standing bug:
https://bugs.python.org/issue29971

Regards

Antoine.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4TNEA5KNWCYTJVIPISUZKVXVDK2BQJWT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Intended invariants for signals in CPython

[Guido van Rossum]

On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou  wrote:

> ...  The intent, though, is that any function
> waiting on an external event (this can be a timer, a socket, a
> lock, a directory...) should be interruptible so that Ctrl-C works in
> an interactive prompt.
>
That’s not really true though right? Locks can block the REPL.

—Guido
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HP2AKFHVS2WLM5XGJMHELHQXSCGQLEPF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Joseph Jenne via Python-Dev]

On 2020-06-25 03:00, Greg Ewing wrote:

On 25/06/20 7:50 pm, Anders Munch wrote:

Pascal is a precedent for this placement of 'case',


Yes, but it doesn't use it with "match". In fact it doesn't have
any keyword in front of the values to be matched; it goes like

   case n of
  1: ...;
  2: ...;
  3: ...;
   end

If we did that in Python it would look like this:

   case shape:
  Point(x, y):
 ...
  Line(x1, y1, x2, y2):
 ...
  Circle(cx, cy, r):
 ...

What think folks of this?

IMHO it looks a lot like shell scripting, which isn't really a bad thing 
in general, but the second form seems to lose some readability to me


--

Joseph

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Rhodri James]

On 25/06/2020 00:54, Tim Peters wrote:

[Ethan Furman ]

"case _:" is easy to miss -- I missed it several times reading through the PEP.


As I said, I don't care about "shallow first impressions".  I care
about how a thing hangs together _after_ climbing its learning curve -
which in this case is about a nanometer tall ;-)

You're not seriously going to maintain that you're struggling to grasp
the meaning of "case _:" now, right?


I'm seriously going to maintain that I will forget the meaning of "case 
_:" quickly and regularly, just as I quickly and regularly forget to use 
"|" instead of "+" for set union.  More accurately, I will quickly and 
regularly forget that in this one place, "_" is special.




while _ does not bind to anything, but of what practical importance is that?) .


One obvious way to do it is of major practical importance.


Yeah, but the "obvious" is being contended, and saying "but it's 
obvious" doesn't really constitute an argument to those of us for whom 
it isn't obvious.



".NAME" grated at first, but extends the idea that dotted names are
always constant value patterns to "if and only if". So it has mnemonic
value.



How do you get from "." to "iff" ?


See reply to Glenn. Can you give an example of a dotted name that is
not a constant value pattern? An example of a non-dotted name that is?
If you can't do either (and I cannot)), then that's simply what "if


  case long.chain.of.attributes:

or more likely

  case (foo.x, foo.y)

for the first.  For the second, it's a no-brainer that you can't have a 
non-dotted name as a constant value pattern, since the current constant 
value pattern mandates a leading dot.



--
Rhodri James *-* Kynesim Ltd
___
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/AW53OVSLMPMFH4PSMDU35SQTCUAVVT2O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[Ivan Pozdeev via Python-Dev]

On 25.06.2020 13:57, Mark Shannon wrote:

Hi,

I'd like to propose the "Anti-PEP".

As I'm sure you've all noticed, contentious PEPs like 572, and now 622, 
generate a lot of email discussion.
It's easy to feel that people's opinions are being dismissed and that 
legitimate criticisms aren't being heard.
Conversely, PEP authors may feel they are being bombarded with criticism, which 
can be overwhelming.

The acceptance, or rejection, of a PEP should be a cool technical decision. Whilst there may be considerations of aesthetics and usability 
that make it difficult to objective, the goal should be to choose what is best for the language in the long term.


When deciding on PEP 484, I had to decide between a formally written PEP on one hand, and a mass of emails and informal polls I had done 
at conferences, on the other.

I hope I made the right decision.

Whether the ultimate decision is made by the steering committee or by a PEP delegate, it is hard to make a decision between the pros and 
cons, when the pros are in a single formal document and the cons are scattered across the internet.


What prevents the cons from being included into a PEP, too?



An Anti-PEP is a way to ensure that those opposed to a PEP can be heard and, if 
possible, have a coherent voice.
Hopefully, it would also make things a lot less stressful for PEP authors.


The Anti-PEP


The Anti-PEP is a single document that describes why a particular PEP should be 
rejected.

An Anti-PEP is not a counter PEP. A counter PEP suggests an alternative solution to the same problem and will often share the same 
motivation as the original PEP. An Anti-PEP would usually reject the motivation or rationale, either as insufficient or as incorrect.


An example of a counter PEP is 576, which was a counter to 575. The motivation was the same, but means proposed was quite different. As a 
result of the ensuing to and fro, we ended up with PEP 590, which was a clear improvement.


I don't have an example of an Anti-PEP.

We could start with PEP 611, https://www.python.org/dev/peps/pep-0611/. There were many criticisms of it on this mailing list, and I can 
promise the PEP author won't be upset by an Anti-PEP :)

Anyone care to volunteer?

Cheers,
Mark.
___
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/JVKWNZEDRXR2IF3KM2JNUF6WT7WETUVK/
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rhodri James]

On 25/06/2020 10:15, Chris Angelico wrote:

On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou  wrote:


On Wed, 24 Jun 2020 12:38:52 -0700
Guido van Rossum  wrote:

Everyone,

If you've commented and you're worried you haven't been heard, please add
your issue *concisely* to this new thread. Note that the following issues
are already open and will be responded to separately; please don't bother
commenting on these until we've done so:

- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
variable binding and '?' for a wildcard.)


I don't know if you read it, so I'll reiterate what I said :-)

"""
Overall, my main concern with this PEP is that the matching semantics
and pragmatics are different from everything else in the language.
When reading and understanding a match clause, there's a cognitive
overhead because suddently `Point(x, 0)` means something entirely
different (it doesn't call Point.__new__, it doesn't lookup `x` in the
locals or globals...).  Obviously, there are cases where this is
worthwhile, but still.



AIUI, the case clauses are far more akin to *assignment targets* than
they are to expressions. If you see something like this:

[x, y] = foo()

then you don't expect it to look up x or y in the current scope, nor
to construct a list.


That argument works for name patterns, but not for class patterns. 
"Cls(x,y)" does not look like an assignment target at all.


--
Rhodri James *-* Kynesim Ltd
___
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/XRKDUCQXHKHV3L4XJPF23BPHKGDBMBAI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

Without arguing for or against allowing a capture variable, IMO rather 
than syntax like

    match  into :
it would be far better (and not require a new keyword) to write this as
    with  as match :
Rob Cliffe
PS:  Or
     = match 

On 24/06/2020 20:38, Guido van Rossum wrote:

Everyone,

If you've commented and you're worried you haven't been heard, please 
add your issue *concisely* to this new thread. Note that the following 
issues are already open and will be responded to separately; please 
don't bother commenting on these until we've done so:


- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to 
mark a variable binding and '?' for a wildcard.)


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



___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
Code of Conduct:http://python.org/psf/codeofconduct/


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JXIY4GKRDAOCMNAVLDACC3S5O5CZ4NQD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[Antoine Pitrou]

On Thu, 25 Jun 2020 11:57:49 +0100
Mark Shannon  wrote:
> 
> An Anti-PEP is a way to ensure that those opposed to a PEP can be heard 
> and, if possible, have a coherent voice.
> Hopefully, it would also make things a lot less stressful for PEP authors.

I don't think this really works.  A PEP has to present a consistent
view of the world, and works as a cohesive whole.  Arguments against a
PEP don't form a PEP in themselves, they don't need to be consistent
with each other; they merely oppose a particular set of propositions.
So an "anti-PEP" would not be anything like a PEP; it would just be a
list of assorted arguments.

Also, in the case of PEP 622, I haven't seen anyone argue against the
PEP in general.  Rather, against specific design decisions in the PEP.

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DJ4IHMF34F7VDOY7RWY6KMPNDQF2MPQE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[Jim F.Hilliard]

A natural question that arises is who will be responsible for authoring it?
I'd guess anyone with a strong enough opinion (and there's no shortage of
those) could be the one who does it.

Separating bikeshedding from refusals/rejections definitely has merit
though, especially for the person making the final decision.

Best Regards,
Jim Fasarakis Hilliard


On Thu, Jun 25, 2020 at 2:08 PM Mark Shannon  wrote:

> Hi,
>
> I'd like to propose the "Anti-PEP".
>
> As I'm sure you've all noticed, contentious PEPs like 572, and now 622,
> generate a lot of email discussion.
> It's easy to feel that people's opinions are being dismissed and that
> legitimate criticisms aren't being heard.
> Conversely, PEP authors may feel they are being bombarded with
> criticism, which can be overwhelming.
>
> The acceptance, or rejection, of a PEP should be a cool technical
> decision. Whilst there may be considerations of aesthetics and usability
> that make it difficult to objective, the goal should be to choose what
> is best for the language in the long term.
>
> When deciding on PEP 484, I had to decide between a formally written PEP
> on one hand, and a mass of emails and informal polls I had done at
> conferences, on the other.
> I hope I made the right decision.
>
> Whether the ultimate decision is made by the steering committee or by a
> PEP delegate, it is hard to make a decision between the pros and cons,
> when the pros are in a single formal document and the cons are scattered
> across the internet.
>
> An Anti-PEP is a way to ensure that those opposed to a PEP can be heard
> and, if possible, have a coherent voice.
> Hopefully, it would also make things a lot less stressful for PEP authors.
>
>
> The Anti-PEP
> 
>
> The Anti-PEP is a single document that describes why a particular PEP
> should be rejected.
>
> An Anti-PEP is not a counter PEP. A counter PEP suggests an alternative
> solution to the same problem and will often share the same motivation as
> the original PEP. An Anti-PEP would usually reject the motivation or
> rationale, either as insufficient or as incorrect.
>
> An example of a counter PEP is 576, which was a counter to 575. The
> motivation was the same, but means proposed was quite different. As a
> result of the ensuing to and fro, we ended up with PEP 590, which was a
> clear improvement.
>
> I don't have an example of an Anti-PEP.
>
> We could start with PEP 611, https://www.python.org/dev/peps/pep-0611/.
> There were many criticisms of it on this mailing list, and I can promise
> the PEP author won't be upset by an Anti-PEP :)
> Anyone care to volunteer?
>
> Cheers,
> Mark.
> ___
> 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/JVKWNZEDRXR2IF3KM2JNUF6WT7WETUVK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KKU6JNU2F7XXEZ6QSOOUJZ6SYMOREMRF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] The Anti-PEP

[Mark Shannon]

Hi,

I'd like to propose the "Anti-PEP".

As I'm sure you've all noticed, contentious PEPs like 572, and now 622, 
generate a lot of email discussion.
It's easy to feel that people's opinions are being dismissed and that 
legitimate criticisms aren't being heard.
Conversely, PEP authors may feel they are being bombarded with 
criticism, which can be overwhelming.


The acceptance, or rejection, of a PEP should be a cool technical 
decision. Whilst there may be considerations of aesthetics and usability 
that make it difficult to objective, the goal should be to choose what 
is best for the language in the long term.


When deciding on PEP 484, I had to decide between a formally written PEP 
on one hand, and a mass of emails and informal polls I had done at 
conferences, on the other.

I hope I made the right decision.

Whether the ultimate decision is made by the steering committee or by a 
PEP delegate, it is hard to make a decision between the pros and cons, 
when the pros are in a single formal document and the cons are scattered 
across the internet.


An Anti-PEP is a way to ensure that those opposed to a PEP can be heard 
and, if possible, have a coherent voice.

Hopefully, it would also make things a lot less stressful for PEP authors.


The Anti-PEP


The Anti-PEP is a single document that describes why a particular PEP 
should be rejected.


An Anti-PEP is not a counter PEP. A counter PEP suggests an alternative 
solution to the same problem and will often share the same motivation as 
the original PEP. An Anti-PEP would usually reject the motivation or 
rationale, either as insufficient or as incorrect.


An example of a counter PEP is 576, which was a counter to 575. The 
motivation was the same, but means proposed was quite different. As a 
result of the ensuing to and fro, we ended up with PEP 590, which was a 
clear improvement.


I don't have an example of an Anti-PEP.

We could start with PEP 611, https://www.python.org/dev/peps/pep-0611/. 
There were many criticisms of it on this mailing list, and I can promise 
the PEP author won't be upset by an Anti-PEP :)

Anyone care to volunteer?

Cheers,
Mark.
___
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/JVKWNZEDRXR2IF3KM2JNUF6WT7WETUVK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Edwin Zimmerman]

On 6/25/2020 3:55 AM, Kyle Stanley wrote:
> 2) Regarding the constant value pattern semantics, I'm okay with the
> usage of the "." in general, but I completely agree with several
> others that it's rather difficult to read when there's a leading
> period with a single word, e.g. ".CONSTANT". To some degree, this
> could probably be less problematic with some reasonably good syntax
> highlighting to draw attention to the leading period.
>
> However, I don't think it should be at all necessary for people to
> rely on syntax highlighting to be able to clearly see something that's
> part of a core Python language feature. It seems especially
> detrimental for those with visual impairment. As someone with
> relatively poor eye-sight who typically has to blow up the font size
> for my code to be readable (and often finds syntax highlighting to be
> distracting), I'm not really looking forward to squinting for missed
> leading periods when it was intended to refer to a constant reference.
> Even if it's a relatively uncommon case, with a core feature, it's
> bound to happen enough to cause some headaches.

A missing . is exactly the type of mistake I tend to make. It is also the type 
of mistake that I could stare at endlessly and not notice.  Surely there could 
be a much more obvious way of doing things.

Other than this . issue, the PEP is great!  I look forward to using match.

--Edwin Zimmerman
___
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/7GGUPIFGKDELBSWPBSUNOZ2CU54KWF2O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Greg Ewing]

On 25/06/20 7:50 pm, Anders Munch wrote:

Pascal is a precedent for this placement of 'case',


Yes, but it doesn't use it with "match". In fact it doesn't have
any keyword in front of the values to be matched; it goes like

   case n of
  1: ...;
  2: ...;
  3: ...;
   end

If we did that in Python it would look like this:

   case shape:
  Point(x, y):
 ...
  Line(x1, y1, x2, y2):
 ...
  Circle(cx, cy, r):
 ...

What think folks of 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/WEYG5Z4FKELPQMFW26R7J5YA3ULBNGP5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Ambient Nuance]

After reading a GitHub discussion on the matter 
(https://github.com/gvanrossum/patma/issues/93), '|' now makes sense to me 
instead of 'or':

- The use of the '|' character in Python seems to be going towards a union-like 
operator (dict merging, PEP 604), which is definitely appropriate here.

- The clarity of '|' and 'or' can go either way subjectivity, but a use-case I 
hadn't considered in my previous comment was nested pattern matching, e.g. 
case (1 | 2 | 3, x) | (4 | 5 | 6, x):
case (1 or 2 or 3, x) or (4 or 5 or 6, x):
To me, '|' seems at least as clear as 'or' in this case, since it can be read 
faster and doesn't chew up space. Spaces before and after '|' definitely help.

- As Tim noted, 'or' would exist as a solitary logical function in the current 
setup. Although, a different GitHub discussion could possibly ressurect 'and' 
(https://github.com/gvanrossum/patma/issues/97).
___
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/4OQET2DXBQUV3ZJNKFUS7O4JB5V7GZ5U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Chris Angelico]

On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou  wrote:
>
> On Wed, 24 Jun 2020 12:38:52 -0700
> Guido van Rossum  wrote:
> > Everyone,
> >
> > If you've commented and you're worried you haven't been heard, please add
> > your issue *concisely* to this new thread. Note that the following issues
> > are already open and will be responded to separately; please don't bother
> > commenting on these until we've done so:
> >
> > - Alternative spellings for '|'
> > - Whether to add an 'else' clause (and how to indent it)
> > - A different token for wildcards instead of '_'
> > - What to do about the footgun of 'case foo' vs. 'case .foo'
> >
> > (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> > variable binding and '?' for a wildcard.)
>
> I don't know if you read it, so I'll reiterate what I said :-)
>
> """
> Overall, my main concern with this PEP is that the matching semantics
> and pragmatics are different from everything else in the language.
> When reading and understanding a match clause, there's a cognitive
> overhead because suddently `Point(x, 0)` means something entirely
> different (it doesn't call Point.__new__, it doesn't lookup `x` in the
> locals or globals...).  Obviously, there are cases where this is
> worthwhile, but still.
>

AIUI, the case clauses are far more akin to *assignment targets* than
they are to expressions. If you see something like this:

[x, y] = foo()

then you don't expect it to look up x or y in the current scope, nor
to construct a list.

Is there any way to make the syntax look more like assignment? Or
maybe this won't even matter - people will simply get used to it with
a bit of experience, same as "for x, y in stuff" has an assignment
target in it.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JGX7PZ6LMSDNS4OWQIJBWGGM6E7V4XO7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Victor Stinner]

Le mer. 24 juin 2020 à 21:16, Stefan Behnel  a écrit :
> It couldn't because even today it is still fairly difficult to convert
> existing code to the limited API. Some code cannot even be migrated at all,
> e.g. because the entire buffer protocol is missing from it. Some bugs were
> only fixed in Py3.9, time will tell if anything else is missing.
>
> The only major project that I know has been migrated (recently, with a lot
> of effort) is the PyQt project. And a GUI toolkit probably doesn't have all
> that many performance critical parts that are dominated by the CPython
> C-API. (I'm just guessing, it probably has some, somewhere).

I created https://bugs.python.org/issue4 to propose to convert a
bunch of stdlib extensions to the limited C API to eat our own dog
food: to ensure that the limited C API is usable, or not just a
"technology demonstration".

I listed missing features of the limited C API, like getbuffer and
releasebuffer.

> We are adding a C compile mode for the limited API to Cython.

That's really great!

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/JMDQXZTKGUIAIH2N5M5Z2AGREVIEO3DW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Intended invariants for signals in CPython

[Antoine Pitrou]

On Wed, 24 Jun 2020 16:54:34 -0700
Yonatan Zunger via Python-Dev  wrote:
> ... Reading through more of the code, I realized that I greatly
> underestimated the number of interruptible operations.
> 
> That said, the meta-question still applies: Are there things which are
> generally intended *not* to be interruptible by signals, and if so, is
> there some consistent way of indicating this?

>From the top of my head, not really.  Most of these (except the points
you marked as "documented with the signal library") are really
implementation details.  The intent, though, is that any function
waiting on an external event (this can be a timer, a socket, a
lock, a directory...) should be interruptible so that Ctrl-C works in
an interactive prompt.

In general, I'd recommend
1) doing as little as possible with signals
2) doing as little as possible in signal handlers

Note that if you do need to use signals, signal.set_wakeup_fd() can
prevent you from interruption and reentrancy issues by allowing to wake
up e.g. an event loop.

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4YBJTG6CZ7KU4SPTK66EMM3B5ZSYHBCA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Antoine Pitrou]

On Wed, 24 Jun 2020 12:38:52 -0700
Guido van Rossum  wrote:
> Everyone,
> 
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
> 
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
> 
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)

I don't know if you read it, so I'll reiterate what I said :-)

"""
Overall, my main concern with this PEP is that the matching semantics
and pragmatics are different from everything else in the language.
When reading and understanding a match clause, there's a cognitive
overhead because suddently `Point(x, 0)` means something entirely
different (it doesn't call Point.__new__, it doesn't lookup `x` in the
locals or globals...).  Obviously, there are cases where this is
worthwhile, but still.

It may be useful to think about different notations for these new
things, rather than re-use the object construction notation.
"""

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HLEPUKFDLNHXXTWMDBSJVAEE6KW3HHE6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Kyle Stanley]

Thank you very much to Brandt, Tobias, Ivan, Guido, and Talin for the
extensive work on this PEP. The attention to detail and effort that
went into establishing the real-world usefulness of this feature (such
as the many excellent examples and code analysis) helps a lot to
justify the complexity of the proposed pattern matching feature(s).
The concern about the added complexity to the language is certainly
reasonable (particularly in the sphere of researchers and other
non-developers), but I think this is a case where practicality will
ultimately win.

Overall, I am +1 for this PEP. That being said, I would like to state
a few opinions (with #2 being my strongest one):

1) I was initially in agreement about the usage "else:" instead of
"match _:", but upon further consideration, I don't think "else:"
holds up very well in the context of pattern matching. Although it
could be confusing at a first glance (admittedly, it threw me off at
first), an underscore makes far more sense as a wildcard match;
especially considering the existing precedent.

2) Regarding the constant value pattern semantics, I'm okay with the
usage of the "." in general, but I completely agree with several
others that it's rather difficult to read when there's a leading
period with a single word, e.g. ".CONSTANT". To some degree, this
could probably be less problematic with some reasonably good syntax
highlighting to draw attention to the leading period.

However, I don't think it should be at all necessary for people to
rely on syntax highlighting to be able to clearly see something that's
part of a core Python language feature. It seems especially
detrimental for those with visual impairment. As someone with
relatively poor eye-sight who typically has to blow up the font size
for my code to be readable (and often finds syntax highlighting to be
distracting), I'm not really looking forward to squinting for missed
leading periods when it was intended to refer to a constant reference.
Even if it's a relatively uncommon case, with a core feature, it's
bound to happen enough to cause some headaches.

>From the "Rejected Ideas" section:

> Introduce a special symbol, for example $ or ^ to indicate that a given name 
> is a constant to be matched against, not to be assigned to:
>
> FOO = 1
> value = 0
>
> match value:
>case $FOO:  # This would not be matched
>...
>case BAR:  # This would be matched
>...
>
> The problem with this approach is that introducing a new syntax for such 
> narrow use-case is probably an overkill.

I can certainly understand that it seems overkill to have a separate
symbol for this, but in my biased opinion, I think it's worth a
stronger consideration from the perspective of those with some degree
of visual impairment. I don't have a strong opinion about the specific
larger symbol that should be used instead, but either of "$" or "^"
would be perfectly fine by me. I'd be on-board with anything that
doesn't have a strong existing purpose in the language.

3) Regarding the 6 before vs. after examples provided by Guido, I have
some thoughts on the last one:

> Original:
>
> def flatten(self) -> Rhs:
> # If it's a single parenthesized group, flatten it.
> rhs = self.rhs
> if (
> not self.is_loop()
> and len(rhs.alts) == 1
> and len(rhs.alts[0].items) == 1
> and isinstance(rhs.alts[0].items[0].item, Group)
> ):
> rhs = rhs.alts[0].items[0].item.rhs
> return rhs
>
> Converted (note that I had to name the classes Alt and NamedItem, which are 
> anonymous in the original):
>
> def flatten(self) -> Rhs:
> # If it's a single parenthesized group, flatten it.
> rhs = self.rhs
> if not self.is_loop():
> match rhs.alts:
> case [Alt(items=[NamedItem(item=Group(rhs=r))])]:
> rhs = r
> return rhs

I think part of it is just that I tend to find anything that has 4+
layers deep of nested parentheses and/or brackets to be a bit
difficult to mentally parse, but my reaction to seeing something like
"case [Alt(items=[NamedItem(item=Group(rhs=r))])]:" in the wild
without anything to compare it to would probably be o_0. I definitely
find the 4-part conditional in the "Original" version to be a lot
easier to quickly understand, even if it's a bit redundant and
requires some guard checks. So IMHO, that specific example isn't
particularly convincing.

That being said, I found the other 5 examples to be very easy to
understand, with the second one being the one to really win me over.
The proposed class matching is a drastic improvement over a massive
wall of "if/elif isinstance(...):" conditionals, and I really like the
way it lines up visually with the constants. Also, in time, I could
very well change my mind about the last example after getting more
used to the proposed syntax.



On Tue, Jun 23, 2020 at 12:04 PM Guido van Rossum  wrote:
>
> I'm happy to present a new PEP for the python-dev community to 

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Anders Munch]

Eric Nieuwland :
>> I have some doubt about the keyword
Guido van Rossum [mailto:gu...@python.org]:
> Many people have tried to come up with a different keyword here, but nothing
> has been found that comes even close to the simplicity of match. Plus, several
> other languages (Scala, Rust) use it too (which is further evidence that it's
> a natural fit).
 
I was thinking that 'match' and 'case' are reversed: The top line presents the
_case_ to be studied.  The patterns that follow try to _match_ the presented 
case.

Trying it out on PEP example:

case input:
match x if x > MAX_INT:
print("Got a large number")

I think it reads well, in particular when like here there's a condition
attached.  The second line is almost English: "match x if x greater than max
int".

Pascal is a precedent for this placement of 'case', although of course Niklaus
Wirth is not a native English speaker either.

regards, Anders

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Greg Ewing]

On 25/06/20 4:24 pm, Emily Bowman wrote:
There's always making everyone equally annoyed, and allowing 'case 
else:'


Visual Basic does actually use "case else". (And "select case"
at the beginning, just to be as annoying as possible.)

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Greg Ewing]

On 25/06/20 8:49 am, Tim Peters wrote:

Spell it,
e.g., "or", and then I wonder "what does short-circuiting have to do
with it?".


Well, it does short-circuit -- if one alternative matches,
it doesn't bother with any subsequent ones. Which could be
considered an argument for using "or" instead of "|".


Names in destructuring constructs are overwhelmingly
intended as lvalues,


That assumes the match statement is going to be used in a
predominantly destructuring way, which I don't think is a
foregone conclusion.

In a destructuring assignment, *all* the names on the LHS
are assignment targets, and *none* on the RHS are, which
makes it easy to see what is being assigned to.

But with these new pattern expressions, either can appear
anywhere in any mixture. While trying to grok the PEP, I
was really struggling to look at something like

   Point(x = a)

and decide whether x or a or neither was being assigned to.
Which makes me think there should be something *really*
clear and unambiguous to indicate when assignment is
happening.

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