[Python-Dev] Pointy brackets for value patterns in Structural Pattern Matching

[Richard Kleijn]

(my first post here after years of lurking)

PEP 635 mentions: "A proposed rule to use a leading dot (e.g. .CONSTANT) for 
that purpose was criticised because it was felt that the dot would not be a 
visible-enough marker for that purpose. Partly inspired by forms found in other 
programming languages, a number of different markers/sigils were proposed (such 
as ^CONSTANT, $CONSTANT, ==CONSTANT, CONSTANT?, or the word enclosed in 
backticks), although there was no obvious or natural choice."

Did anyone consider using pointy brackets to express a value pattern? To me 
they feel much more natural than the dismissed sigils/markers mentioned above.

Searching the mailing list it seems that so far pointy brackets only have been 
proposed for *capture* patterns.
 
I just read the thread David Mertz recently started (on the idea to use words 
rather than sigils). It occurred to me that the example he used can be quite 
neatly expressed using pointy brackets:


NOT_FOUND = 404
match http_code:
case 200:
print("OK document")
case :  # use the variable value
print("Document not found")
case other_code:  # bind this name
print("Other HTTP code", other_code)


There is also some precedent for syntax like this. Everyone who has seen 
command-line interface descriptions such as:

Usage: 
  my_program  

will be able to intuitively grasp the meaning that it is about the *value* of 
the thing between the pointy brackets.


Could this be a viable idea?

Best regards,
Richard
___
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/EJ43KICIU5X4AYRDQJY2XK2QTCX6CJIN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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

I *hope* this was a typo!  If

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

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


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

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

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

then if you get it wrong and write

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

at least you'll get a syntax error.

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

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

[Greg Ewing]

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

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


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

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

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


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

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

--
Greg

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

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

[Glenn Linderman]

On 11/13/2020 1:48 PM, Joao S. O. Bueno wrote:



On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett > wrote:


I *hope* this was a typo!  If

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

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


No typo -  this is _precisely_what the main proposal on PEPs 634, 635 
and 636 is suggesting, and tha PEP 642 is trying to avoid.


And the claim is, that there are people that think this is a good idea❓❓ 
And are actually proposing to add it to Python❓



Here it is working as is  on my Python with PEP 622 build:

```
Python 3.10.0a0 (heads/patma:1ba56a003b, Aug  6 2020, 02:00:58)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.17.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: fromdataclassesimportdataclass

In [2]: @dataclass
  ...: classPoint:
  ...: x: float
  ...: y: float
  ...:

In [3]: defget_coords(p):
  ...: match p:
  ...: case Point(x=a, y=b):
  ...: returna, b
  ...: case _:
  ...: raiseTypeError()
  ...:

In [4]: get_coords(Point(3, 4))
Out[4]: (3, 4)

```


-jJ



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

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

[Joao S. O. Bueno]

On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett  wrote:

> I *hope* this was a typo!  If
>
> case Point(x=a, y=b):
>
> assigns to a and b (instead of x and y, as in a normal call), then that is
> ... going to be very easy for me to forget, and to miss even when I'm aware
> of it.
>

No typo -  this is _precisely_what the main proposal on PEPs 634, 635 and
636 is suggesting, and tha PEP 642 is trying to avoid.
Here it is working as is  on my Python with PEP 622 build:

```
Python 3.10.0a0 (heads/patma:1ba56a003b, Aug  6 2020, 02:00:58)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.17.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from dataclasses import dataclass


In [2]: @dataclass
  ...: class Point:
  ...: x: float
  ...: y: float
  ...:


In [3]: def get_coords(p):
  ...: match p:
  ...: case Point(x=a, y=b):
  ...: return a, b
  ...: case _:
  ...: raise TypeError()
  ...:


In [4]: get_coords(Point(3, 4))

Out[4]: (3, 4)

```



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

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

[Jim J. Jewett]

I *hope* this was a typo!  If 

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

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

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

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

[Joao S. O. Bueno]

On Fri, 13 Nov 2020 at 15:53, Brandt Bucher  wrote:

> Paul Sokolovsky wrote:
> > Use punctuation ("sigils") to mark as-binding terms. This choice still
> seems to be under-considered. (As in: it doesn't seem like many people,
> including the PEP authors, tried to say "indeed, what if?" and feel thru
> it. I mean, try really hard. I trust the "gang of 4" spent maybe whole few
> hours on that and delivered "no" to all us. It's still not the same as
> dozens of people trying it over a few months).
>
> To anyone actually wondering how much time and mental energy we’ve spent
> on a particular issue: please take a look at our tracker before guessing
> “maybe whole few hours”:
>
> - Issue #1(!), April, 29 comments:
> https://github.com/gvanrossum/patma/issues/1
> - Issue #90, June, 84 comments:
> https://github.com/gvanrossum/patma/issues/90
> - Issue #92, June, 33 comments:
> https://github.com/gvanrossum/patma/issues/92
> - Issue #105, June, 17 comments:
> https://github.com/gvanrossum/patma/issues/105
> - Issue #143, August, 7 comments:
> https://github.com/gvanrossum/patma/issues/143
>
> (I won't judge anyone for skimming a bit; it's a *lot* of discussion. Do
> note, though, that for months I was one of the proponents of store sigils
> like `?` until I was eventually convinced otherwise.)
>
> That's also not counting side-discussions in other issues, countless
> mailing list threads, two competing PEPs that make many of the same
> choices, a video call with the SC, etc.
>
> I'll also add, for anyone considering choosing yet another ASCII symbol
> off their keyboard and proposing it as a “novel”, “intuitive” marker: one
> problem with most of the hastily suggested adornments are that they do not
> nest very well, for even simple cases. Further, the fact that constructions
> like `p = Point(x, y)` look exactly the same as deconstructions like `case
> Point(x, y):` is absolutely intentional (which touches back on Guido’s
> “rhyme” comment last night).
>
> Very briefly, compare the current syntax:
>
> ```
> case first, *middle, last:
> rebuilt = first, *middle, last
> case {"key": value, **rest}:
> rebuilt = {"key": value, **rest}
> case Point(x=a, y=b):
> rebuilt = Point(x=a, y=b)
> ```
>
> with (using your own syntactic flavor):
>
> ```
> case >first, *>middle, >last:
> rebuilt = first, *middle, last
> case {"key": >value, **>rest}:
> rebuilt = {"key": value, **rest}
> case Point(x=>a, y=>b):
> rebuilt = Point(x=a, y=b)
> ```
>

Well, this example is a bit unfair, since you don't present a case where
there would be
matching values in variables that we would want to compare - which is the
solution
that is being brought up.

And even in that case, while I can see:

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

and immediately read it as "attribute x from point goes into a",
the line in the current proposal doing the same:
case Point(x=a, y=b):
is far from being immediately obvious (Am I creating a new Point?
Am i assigning "a" to "x"? If so, where does "a" come from??)



> (I had to stop and think *hard* where exactly the `>` should go in
> `*middle` and `**rest`. I'm not confident I made the correct guess, either.)
> ___
> 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/7SJ2SOPRD6XOAISOYXONKXUKB3JMLYNU/
> 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/KTRXIM7A3OATCHZZXBULLSNZZ3BNSGJK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brandt Bucher]

Paul Sokolovsky wrote:
> Use punctuation ("sigils") to mark as-binding terms. This choice still seems 
> to be under-considered. (As in: it doesn't seem like many people, including 
> the PEP authors, tried to say "indeed, what if?" and feel thru it. I mean, 
> try really hard. I trust the "gang of 4" spent maybe whole few hours on that 
> and delivered "no" to all us. It's still not the same as dozens of people 
> trying it over a few months).

To anyone actually wondering how much time and mental energy we’ve spent on a 
particular issue: please take a look at our tracker before guessing “maybe 
whole few hours”:

- Issue #1(!), April, 29 comments: https://github.com/gvanrossum/patma/issues/1
- Issue #90, June, 84 comments: https://github.com/gvanrossum/patma/issues/90
- Issue #92, June, 33 comments: https://github.com/gvanrossum/patma/issues/92
- Issue #105, June, 17 comments: https://github.com/gvanrossum/patma/issues/105
- Issue #143, August, 7 comments: https://github.com/gvanrossum/patma/issues/143

(I won't judge anyone for skimming a bit; it's a *lot* of discussion. Do note, 
though, that for months I was one of the proponents of store sigils like `?` 
until I was eventually convinced otherwise.)

That's also not counting side-discussions in other issues, countless mailing 
list threads, two competing PEPs that make many of the same choices, a video 
call with the SC, etc.

I'll also add, for anyone considering choosing yet another ASCII symbol off 
their keyboard and proposing it as a “novel”, “intuitive” marker: one problem 
with most of the hastily suggested adornments are that they do not nest very 
well, for even simple cases. Further, the fact that constructions like `p = 
Point(x, y)` look exactly the same as deconstructions like `case Point(x, y):` 
is absolutely intentional (which touches back on Guido’s “rhyme” comment last 
night).

Very briefly, compare the current syntax:

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

with (using your own syntactic flavor):

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

(I had to stop and think *hard* where exactly the `>` should go in `*middle` 
and `**rest`. I'm not confident I made the correct guess, either.)
___
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/7SJ2SOPRD6XOAISOYXONKXUKB3JMLYNU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Thu, Nov 12, 2020 at 11:41 PM Paul Sokolovsky  wrote:

> Hello,
>
> On Thu, 12 Nov 2020 12:51:19 -0800
> Guido van Rossum  wrote:
>
> > I have a meta-observation. Clearly there are too many cooks here. The
> > same suggestions keep getting brought up. We will never converge on a
> > design this way.
>
> Right, it's not a Python decision unless it's forced thru like PEP572,
> aka the ":=" (https://lwn.net/Articles/757713/ , etc.). Can also
> remember the whole Python3 migration business
> (
> https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/
> ,
> etc).
>

Please keep the conversation civil.

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-11-06 - 2020-11-13)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7628 (+11)
  closed 46459 (+62)
  total  54087 (+73)

Open issues with patches: 3064 


Issues opened (60)
==

#32426: Tkinter: reference document of possible cursor names
https://bugs.python.org/issue32426  reopened by terry.reedy

#32682: test_zlib improve version parsing
https://bugs.python.org/issue32682  reopened by pmpp

#40077: Convert static types to heap types: use PyType_FromSpec()
https://bugs.python.org/issue40077  reopened by pitrou

#40137: TODO list when PEP 573 "Module State Access from C Extension M
https://bugs.python.org/issue40137  reopened by vstinner

#40939: Remove the old parser
https://bugs.python.org/issue40939  reopened by vstinner

#41832: PyType_FromSpec() should accept tp_doc=NULL
https://bugs.python.org/issue41832  reopened by petr.viktorin

#42131: [zipimport] Update zipimport to use specs
https://bugs.python.org/issue42131  reopened by brett.cannon

#42273: Using LazyLoader leads to AttributeError
https://bugs.python.org/issue42273  reopened by brett.cannon

#42280: The list of standard generic collections is incomplete
https://bugs.python.org/issue42280  opened by jack1142

#42281: Inconsistent ProcessPoolExecutor behaviour on macOS between 3.
https://bugs.python.org/issue42281  opened by mustafaquraish

#42286: f_trace gets call on different lines each loop
https://bugs.python.org/issue42286  opened by MegaIng

#42287: Use Py_NewRef & Py_XNewRef where applicable
https://bugs.python.org/issue42287  opened by Yonatan Goldschmidt

#42289: Found a secret/private key in code.
https://bugs.python.org/issue42289  opened by krrishdhaneja

#42290: Unicode inconsistent display after concencated
https://bugs.python.org/issue42290  opened by xxm

#42291: Incorrect signature of CodeType.replace()
https://bugs.python.org/issue42291  opened by serhiy.storchaka

#42292: C API: Allocating Objects on the Heap. Misleading documentatio
https://bugs.python.org/issue42292  opened by igo95862

#42293: Installation of pyinstaller in Windows fails with utf8 error
https://bugs.python.org/issue42293  opened by giomach

#42294: [C API] Add new C functions with more regular reference counti
https://bugs.python.org/issue42294  opened by vstinner

#42297: [argparse] Bad error message formatting when using custom usag
https://bugs.python.org/issue42297  opened by TurboTurtle

#42298: Documented interaction of single-stage init and sub-interprete
https://bugs.python.org/issue42298  opened by pkerling

#42299: Add test_formatter (or remove deprecated formatter module?)
https://bugs.python.org/issue42299  opened by terry.reedy

#42300: Typo in translation to portuguese
https://bugs.python.org/issue42300  opened by ronan.soares

#42302: [Turtle] Add clockwise and anticlockwise method as alias to ri
https://bugs.python.org/issue42302  opened by zenr

#42304: [easy C] long type performance waste in 64-bit Windows build
https://bugs.python.org/issue42304  opened by malin

#42305: Added Auto_Complete DropBox Suggestion For Tkinter
https://bugs.python.org/issue42305  opened by RajvirSingh1313

#42306: wrong exception handling in case asyncio.shiled usage
https://bugs.python.org/issue42306  opened by Alex Alex

#42307: make install must not copy python.o into $prefix/lib/python3.1
https://bugs.python.org/issue42307  opened by vstinner

#42309: BUILD: AIX-64-bit segmentation fault
https://bugs.python.org/issue42309  opened by Michael.Felt

#42315: `python -m` semantics conflict with `__file__`'s being optiona
https://bugs.python.org/issue42315  opened by William.Schwartz

#42316: Walrus Operator in list index
https://bugs.python.org/issue42316  opened by Brando753

#42317: Docs of `typing.get_args`: Mention that due to caching of typi
https://bugs.python.org/issue42317  opened by Dominik V.

#42318: [tkinter] surrogate pairs in Tcl/Tk string when pasting an emo
https://bugs.python.org/issue42318  opened by ronaldoussoren

#42321: Limitations of building a static python library on Windows (MS
https://bugs.python.org/issue42321  opened by maarten

#42322: Spectre mitigations in CPython interpreter
https://bugs.python.org/issue42322  opened by sahnaseredini

#42323: [AIX] test_math: test_nextafter(float('nan'), 1.0) does not re
https://bugs.python.org/issue42323  opened by vstinner

#42324: Doctest: directives
https://bugs.python.org/issue42324  opened by konrad.schwarz

#42325: UnicodeDecodeError executing ./setup.py during build
https://bugs.python.org/issue42325  opened by skip.montanaro

#42327: Add PyModule_Add()
https://bugs.python.org/issue42327  opened by serhiy.storchaka

#42328: ttk style.map function incorrectly handles the default state f
https://bugs.python.org/issue42328  opened by patthoyts

#42330: Add browsh in the webbrowser module

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Steve Holden]

On Thu, Nov 12, 2020 at 8:49 PM Guido van Rossum  wrote:

> The correct place for the docs for __cause__ and __context__ is in the
> section in the library reference about exceptions. There's quite a bit
> about them there already. That's where the tutorial should link as well.
>
> And now I ask you to stop complaining (your "the PEPs are the worst" does
> not help your cause).
>
> On Thu, Nov 12, 2020 at 12:30 PM Riccardo Polignieri via Python-Dev <
> python-dev@python.org> wrote:
>
>> > There is value in having non-trivial coverage of the language.  When
>> people ask how
>> > __cause__ works, we can link to the tutorial.
>> [...]
>
>
A Google search here for

python tutorial __cause__

returns as its first hit https://docs.python.org/3/library/exceptions.html
(the very section to which it seems you refer). There is a terse but
adequate description of __cause there__. It seems unhelpful that the
permalink for __cause__ (
https://docs.python.org/3/library/traceback.html?highlight=__cause__#traceback.TracebackException.__cause__)
links back to itself, but that's the nature of the beast with nested
exceptions -- it's __cause__s and __context__s all the way down.

A search for __cause__ using the documentations search feature leads to the
same loop of links noted above. In either case, if the curious reader
follows the traceback_exception link (
https://docs.python.org/3/library/traceback.html?highlight=__cause__#traceback.TracebackException)
they are moved up five lines whereupon the context becomes more
obvious.Those who find it intimidating may be a little out of their
depth, as this is hardly beginner material.

The tutorial was not mentioned in the docs search and the third hit in
my Google search, linking to https://docs.python.org/3/tutorial/errors.html.
Somewhat ironically, __cause__ is not mentioned on that page.
___
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/FU5CQKXAZD5KK54KFOE26JM636MHFJYO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Baptiste Carvello]

Hi,

Le 12/11/2020 à 18:55, Guido van Rossum a écrit :
> The position of PEP 622/634/535/636 authors is clear: 

well, let me first emphasize that I did *not* mean to reopen the
discussion on those PEPs, which explain and discuss their design choices
thoroughly (even better since the rewrite, thanks for that). And I
definitely did not mean to spawn another "mark capture or value"
subthread… I thought "PEP 642 v2" in the thread title was explicit
enough, should have been more cautious :-)

PEP 642 states as a design principle that parallelism between patterns
and assignments should be kept as much as possible (let's not discuss
this principle here). Thus, introducing different semantics for dotted
names deserves a discussion in that PEP (by contrast, literal
constraints need little discussion, because they have no semantics in
assignments).

> we see this as a
> necessary feature to support using enums (e.g. Color.RED) or constants
> defined in other modules (e.g. re.I) when simple switch functionality is
> being migrated from literals (e.g. case 404) to named constants (e.g.
> case HTTPStatus.NOT_FOUND). Bothering users with the technicality of
> needing to use '==' here is a big usability hit.

Indeed, enums and other dotted constants are the heart of the matter.
And I get your point about not making useful refactoring more difficult.
Still it could make sense (in the philosophy of PEP 642, again) to defer
the choice and see how strong the need is. What PEP 642 ends up
proposing will be Nick Coghlan's call.

Cheers,
Baptiste

P.S.: a few examples for "taste":

# your example
match status:
  case == HTTPStatus.NOT_FOUND:
...

vs. case HTTPStatus.NOT_FOUND:

# worst-case where constants are buried in the pattern
match sock:
  case socket(family=(==socket.AF_INET), type=(==socket.SOCK_STREAM)):
...

vs. case socket(family=socket.AF_INET, type=socket.SOCK_STREAM):

# same with plain constants, PEP 642 only
match sock:
  case socket(family=(==AF_INET), type=(==SOCK_STREAM)):
...
___
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/CZWZRN5J6QIJZM2C4IUOBGCWNJ7EM6QX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Luciano Ramalho]

On Thu, Nov 12, 2020 at 8:41 PM David Mertz  wrote:
> One idea that I cannot recall seeing, but that seems to make sense to me and 
> fit with Python's feel is using a WORD to distinguish between a variable 
> value and a binding target.  That is, instead of a special symbol prefixing 
> or suffixing a name, either to indicate it is or is not a binding target.  Of 
> course, whether the extra word would be used for binding or for NOT binding 
> is a question still.

I agree 100%. Words instead of sigils is more like the rest of Python.

Best,

Luciano


>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case value NOT_FOUND:  # use the variable value
> print("Document not found")
> case OTHER_CODE:  # bind this name
> print("Other HTTP code", OTHER_CODE)
>
> Of course, this would require a soft keyword, which is a disadvantage.  Going 
> the other direction:
>
> NOT_FOUND = 404
> match http_code:
> case 200:
> print("OK document")
> case NOT_FOUND:  # use the variable value
> print("Document not found")
> case bind OTHER_CODE:  # bind this name
> print("Other HTTP code")
>
> To me these read better than the punctuation characters.  But I guess some 
> folks have suggested enlisting 'as', which is a word, of course.
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
> ___
> 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/5YUWE7K6LX3VZIISURABRBCEIGMYDUCS/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/SNOU3YVKLQDA4SUBWX5L22XEGSKZBIVX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Sokolovsky]

Hello,

On Fri, 13 Nov 2020 21:51:49 +1100
Steven D'Aprano  wrote:

> > match foo:
> > case ("foo", >val1):
> > ...
> > case ("bar", >val2):
> > ...  
> 
> > 1. Much more intuitive for beginners. (If Python adopts it, I see
> > other "user-friendly" languages adopting the same pattern in the
> > coming decades).  
> 
> I think you and I have a very different concept of "intuitive for 
> beginners" here. I don't think that using the *greater than symbol*
> as a sigil for assignment would have been "intuitive" to me as a
> beginner, or anyone I have helped teach over the years.

Treat it as "arrow pointing into a variable identifier, meaning that
value is getting into variable". ">>" and "->" are other alternatives
with the same intuitive connotation. ">>" is a particularly interesting
choice, as it should give warm fuzzy feelings (and partial moral
compensation) to all folks who miss the print statement
('print >>sys.stderr, "foo"').

[]

> > # Why is this possible?
> > obj.foo, obj.bar = val
> > 
> > # And this is not?
> > match val:
> > case obj.foo, obj.bar:  
> 
> 
> I agree with this. I think it is surprising that unqualified names
> are binding patterns but qualified names are not. That difference
> gives me pause.

But *that's the problem* we're trying to solve!

Aka, stop resolving binding-vs-value ambiguity by assigning semantic
discrepancies to different *syntactic* patterns, and instead, consider
using *punctuation* to resolve the ambiguity. And then there're 2
choices.

1. Use punctuation ("sigils") to mark as-value terms (expressions).
This is now well (enough) covered in PEP642, from which this thread
is, well, started.
 
2. Use punctuation ("sigils") to mark as-binding terms. This choice
still seems to be under-considered. (As in: it doesn't seem like many
people, including the PEP authors, tried to say "indeed, what if?"
and feel thru it. I mean, try really hard. I trust the "gang of 4"
spent maybe whole few hours on that and delivered "no" to all us. It's
still not the same as dozens of people trying it over a few months).

> But using `>` as an assignment sigil is surely worse
> than the problem you hope to solve with it.

">" is just a notation mark and one of many possible choices. ">", "->",
">>", "@", "$" were mentioned before, and today, even word-fulls like
"bind" were proposed (thread "Words rather than sigils in Structural
Pattern Matching"). All valid choices to consider, *once* we agree that
it is a viable idea to mark bind-terms, on par with other alternatives,
and not a throw-away "misconception", how PEP635 tries to represent it
(https://www.python.org/dev/peps/pep-0635/#capture-patterns)


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/6HNB5JDA4SI2R6PM6KSQ24WYW2CLBEWW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Thu, Nov 12, 2020 at 09:40:02PM +0300, Paul Sokolovsky wrote:


> match foo:
> case ("foo", >val1):
> ...
> case ("bar", >val2):
> ...

> 1. Much more intuitive for beginners. (If Python adopts it, I see
> other "user-friendly" languages adopting the same pattern in the
> coming decades).

I think you and I have a very different concept of "intuitive for 
beginners" here. I don't think that using the *greater than symbol* as a 
sigil for assignment would have been "intuitive" to me as a beginner, or 
anyone I have helped teach over the years.

To me, that statement clearly and obviously could only mean one possible 
thing:


* match a two-sequence where the first item equals "foo" and the 
  second is greater than `val1`;


(and similarly for the second case statement).

Are there any other languages that use `>` as a prefix sigil to indicate 
assignment?

If we were to use a sigil to represent binding, surely `=` would make 
more sense than `>`.


> 2. Upholds the rights of people who see "match" as glorified "switch"
> statement, 

There is no right for people to dictate that syntax must support their 
misapprehensions about language features. Or for that matter, no right 
to dictate *anything* about syntax. There is no universal human right to 
dictate Python syntax.

The best you have is the privilege to attempt to persuade others to 
support your preference, and for the Steering Council to be swayed by 
your arguments and/or the popular support for your preference.


> and not keen on it doing assignments behind their backs. (The
> topic which was recently mentioned on the list.)

How is it doing assignments behind your back? The syntax is clear: a 
name is a binding pattern. That is as much an explicitly assignment 
statement as import, for, with...as, def or class.

This is an assignment "behind your back":


def sneaky_assignment():
global x
x = 999

sneaky_assignment()


There's nothing in the call to `sneaky_assignment` to hint that it 
assigns a value to the global `x`. Pattern matching is nothing like 
that: all binding patterns are explicit, all you need is to get past the 
misapprehension that pattern matching is a switch statement (it isn't!) 
and it will be clear as daylight:

case 1, x: pass

Of course x gets assigned to. It's a binding pattern.

import sys

Of course sys gets assigned to. It's an import.



> 3. Solves discrepancy with cases like:
> 
> # Why is this possible?
> obj.foo, obj.bar = val
> 
> # And this is not?
> match val:
> case obj.foo, obj.bar:


I agree with this. I think it is surprising that unqualified names are 
binding patterns but qualified names are not. That difference gives me 
pause. But using `>` as an assignment sigil is surely worse than the 
problem you hope to solve with it.


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