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

[Marco Sulla]

On Tue, 17 Nov 2020 at 03:52, Steven D'Aprano  wrote:

> Here is a more representative example, borrowed from here:
>
> https://gvanrossum.github.io//docs/PyPatternMatching.pdf
>
>
> match node:
> case BinOp(Num(left), '+', Num(right)):
> return Num(left + right)
> case BinOp(left, '+' | '-', Num(0)):
> return simplify(left)
> case UnaryOp('-', UnaryOp('-', item)):
> return simplify(item)
> case _:
> return node
>
>
> which becomes this with the "as" proposal:
>
>
> match node:
> case BinOp(Num(as left), '+', Num(as right)):
> return Num(left + right)
> case BinOp(as left, '+' | '-', Num(0)):
> return simplify(left)
> case UnaryOp('-', UnaryOp('-', as item)):
> return simplify(item)
> case _:
> return node
>

Well, I like the idea to have a keyword instead of a sigil, but `as` does
not sounds good in English IMO. For example, in the `with` statement, it's

with x as y:
[code]

I see the pattern matching code and I ask myself: where is the x?

PS: pattern matching, for a mere mortal like me, seems to be something very
exotical. That's why an explicit, even if verbose, additional keyword seems
to me better for reading and understanding the code. For my eyes, it's the
same difference between

x = y ? z : w
and
x = y if z else w
___
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/6HPPFZNEEAWVPHC5XRA7TVPXKASF7AXW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Sat, Nov 14, 2020 at 11:11:37PM +1000, Nick Coghlan wrote:
> On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
> >
> > I have read a great deal of discussion on the pattern matching PEPs and 
> > less formal discussions.  It is possible I have overlooked some post in all 
> > of that, of course.
> >
> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose applies 
> > to this too :-).
> >
> > 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.
> 
> If someone was prepared to pursue this to the level of writing a 3rd
> competing PEP, the variant I would personally like to see written up
> is the one where capture patterns are all prefixed with the keyword
> `as`.
> 
> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
> match patterns with a capture pattern, and I'm going to be amending
> PEP 642 to propose using `as` when embedding capture patterns inside
> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
> From there, it's an entirely plausible step to also require the `as`
> prefix on capture patterns in sequence patterns and as top level
> standalone patterns.
> 
> I personally don't think that extra step would be a good idea due to
> the inconsistency with name binding and iterable unpacking in regular
> assignment statements (if I liked the idea, I'd have already included
> it in PEP 642), but I think "anchor match patterns in normal
> expressions rather than assignment target syntax" is a credible enough
> idea that the overall design process would benefit from having a
> champion write it up.
> 
> > To me these read better than the punctuation characters.  But I guess some 
> > folks have suggested enlisting 'as', which is a word, of course.
> 
> Indeed, and one that doesn't look too bad for top level patterns:
> 
> NOT_FOUND = 404
> match http_code:
>   case 200:
>   print("OK document")
>   case NOT_FOUND:  # use the variable value
>   print("Document not found")
>   case as other_code:  # bind this name
>   print("Other HTTP code")

It doesn't look too bad because it looks like a switch statement, with 
only one lonely capture pattern, and an especially simple one at that. 
(The bound name isn't even used, which strongly suggests that it should 
be written as the wildcard pattern.)

Here is a more representative example, borrowed from here:

https://gvanrossum.github.io//docs/PyPatternMatching.pdf


match node:
case BinOp(Num(left), '+', Num(right)):
return Num(left + right)
case BinOp(left, '+' | '-', Num(0)):
return simplify(left)
case UnaryOp('-', UnaryOp('-', item)):
return simplify(item)
case _:
return node


which becomes this with the "as" proposal:


match node:
case BinOp(Num(as left), '+', Num(as right)):
return Num(left + right)
case BinOp(as left, '+' | '-', Num(0)):
return simplify(left)
case UnaryOp('-', UnaryOp('-', as item)):
return simplify(item)
case _:
return node


Here's another example from the same paper:


def create_rectangle(*args, **kwargs):
match (args, kwargs):
case ([x1, y1, x2, y2], {}) if x2-x1 == y2-y1:
return Square(x1, y1, x2-x1)
case ([x1, y1, x2, y2], {}):
return Rect(x1, y1, x2, y2)
case ([(x1, y1), (x2, y2)], {}):
return Rect(x1, y1, x2, y2)
case ([x, y], {'width': wd, 'height': ht}):
return Rect(x, y, x+wd, y+ht)


which would become:


def create_rectangle(*args, **kwargs):
match (args, kwargs):
case ([as x1, as y1, as x2, as y2], {}) if x2-x1 == y2-y1:
return Square(x1, y1, x2-x1)
case ([as x1, as y1, as x2, as y2], {}):
return Rect(x1, y1, x2, y2)
case ([(as x1, as y1), (as x2, as y2)], {}):
return Rect(x1, y1, x2, y2)
case ([as x, as y], {'width': as wd, 'height': as ht}):
return Rect(x, y, x+wd, y+ht)



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

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Barry Warsaw]

On Nov 16, 2020, at 11:51, Paul Ganssle  wrote:
> 
> Not to put words in Barry's mouth, but I took Barry's comment to be more an 
> answer to the question of how to contact "distro packagers" as a group, more 
> than he was taking a position about this particular issue.

Correct!

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/TTZGJGXIWTQTKMWZCPYVYSNNIOVF365Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Terry Reedy]

On 11/16/2020 11:57 AM, Tobias Kohn wrote:

1.  This really comes down to how you look at it, or how you define 
pattern matching.  The issue here is that the concept of pattern 
matching has grown into a large and somewhat diverse flock of 
interpretations and implementations (as a side note: interestingly 
enough, some of the only universally agreed-upon standards are to use 
`_` as a wildcard and not to mark names that capture/bind values---which 
are quite exactly the points most fiercely debatted here).


_ looks OK to me.  I was not aware of the 'standard' for name usage. 
But I just noticed the following:


Anyway, the paper presents the pattern matching structure we are 
proposing as one of three major variants of pattern matching:

(a)  Matching arguments to parameters in a function call,


Binding names are in the function definition and parameter signature, 
which is the pattern.  Except for default argument expressions, value 
names are in the call that provided the data to be matched.



(b)  Matching elements to elements in iterable unpacking,


Binding names are in the target pattern on the left.  Value names are in 
the data source expression on the right.


(c)  Matching tree-like data to general patterns in a conditional 
pattern matching structure.


Oh dear.  We need both binding and value names in patterns.  In
  case BinOp(Num(left), '+', Num(right)):
obviously callable names BinOp and Num are treated as value names, with 
their signatures providing subpatterns.  The not-obviously-callable 
names left and right are treated as binding names.


I think that Python matching should use the all-caps convention.  I like 
reusing the existing 'as x' syntax.


I see if-elif-else structures, with assignment expressions included, as 
existing but limited conditional pattern matching structures.  Binding 
names are clearly marked with ':='.

---

Separate item: The Program 1 fact def needs a guard "if n > 1 and int(n) 
== n" to not raise Recursion error for negative and fractional args.



--
Terry Jan Reedy

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

[Python-Dev] Re: [python-committers] Re: Steering Council Election Timeline for 2021 term

[Brett Cannon]

Ernest closed the nominations and we ended up with 10 nominees! Thanks to
everyone who stepped forward to serve on the SC.

I would like to encourage people to take the time to read everyone's
nomination posts as stances on a wide variety of topics ranging from
pattern matching to the Code of Conduct are covered by them. And with
Victor not running again, there's going to be, at minimum, one new person
on the SC in 2021.

https://discuss.python.org/c/core-dev/steering-council-nominations/21

On Sun, Nov 15, 2020 at 9:18 AM Victor Stinner  wrote:

> Reminder: the deadline for nomination is tonight, hurry up ;-)
>
> Current candidates can be found at:
> https://discuss.python.org/c/core-dev/steering-council-nominations/21
>
> Victor
>
> Le mer. 28 oct. 2020 à 20:55, Ewa Jodlowska  a écrit :
> >
> > Hi!
> >
> > The timeline for this year's election will be the same as last year.
> >
> > * The nomination period will begin Nov 1, 2020 (do not post nominations
> until then)
> > * Nomination period will end Nov 15, 2020
> > * Voting will begin Dec 1, 2020
> > * Voting will end Dec 15, 2020
> >
> > Nominations will be collected via https://discuss.python.org/ (more
> details to follow on Nov 1).
> >
> > New for this year: Ernest W. Durbin III will be running the vote along
> with the assistance of Joe Carey, a PSF employee. They will be co-admins
> going forward. I have cc'ed them in on this thread as well in case there
> are any questions.
> >
> > Thanks,
> >
> > Ewa
> >
> > ___
> > python-committers mailing list -- python-committ...@python.org
> > To unsubscribe send an email to python-committers-le...@python.org
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/JHYSU6FEYM3A5AZXSICO5OE3VAWDPGEJ/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/LTAY635DKLMR2655CQN2S5Z7YBILDF24/
> Code of Conduct: https://www.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/CECK4QMWBDUAS4EXYQAZBVWBC6R3S6KS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Paul Ganssle]

Good to know. I think one reason I wouldn't immediately think to send
things to Linux-SIG is that for me "distro packagers" also includes
people maintaining packages in the BSD, Solaris, conda-forge, homebrew,
etc ecosystems. It might make sense to have a dedicated list or
discourse for distro packagers, but as I don't meet the description I
don't know how useful it would be for me to opine on the form it should
take.

Best,
Paul

On 11/16/20 10:45 AM, Miro Hrončok wrote:
> On 11/16/20 4:10 PM, Paul Ganssle wrote:
>>> Maybe it would make sense to create a community mailing list for
>>> packagers?
>> That sounds like a good idea to me.
>
> I am following the Linux SIG mailing list. But it's mostly dead.
>
> https://mail.python.org/archives/list/linux-...@python.org/
>
___
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/JSGVNDBFNDZ6WHGVUA23PMXRVPHN6IQU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Paul Ganssle]

> why is this dependency needed?  The tzdata package is marked with Priority
> required. See Debian policy 2.5.
>
> Matthias

Not to put words in Barry's mouth, but I took Barry's comment to be more
an answer to the question of how to contact "distro packagers" as a
group, more than he was taking a position about this particular issue.

That said, as I mentioned on the launchpad

and elsewhere in this thread, I think that, in general, it makes sense
to have an explicit dependency on tzdata as a clear indicator that we
actually have a direct dependency on tzdata, even if it's not
technically required because it's satisfied automatically for some
reason. It would make it easier for people to find packages that depend
on tzdata to notify us of issues (I've done something like this before —
`tzlocal` is planning to make a backwards-incompatible change to using
`zoneinfo`, and when I found out about this I dug up all the projects I
could find that explicitly depend on `tzlocal` to notify them of the
upcoming change).

It also is less fragile. As Christian mentioned in the launchpad issue,
zoneinfo is actually broken without a direct dependency on tzdata in the
ubuntu docker container — possibly that's a bug in the way the ubuntu
docker contianer is packaged, but it wouldn't be a problem for /us/ if
python had a dependency on tzdata. As far as I can tell it also wouldn't
hurt anything for this dependency to be made explicit rather than implicit.

That said — it's entirely up to individual package maintainers how they
want to handle their dependency metadata. The important thing I wanted
to convey to distro maintainers is that PEP 615 effectively is saying
that Python now depends on the system metadata package being present. If
there's no need to do anything because tzdata is an implicit dependency
for the entire Debian ecosystem then that's fine.

Best,
Paul

On 11/16/20 2:15 PM, Matthias Klose wrote:
> On 11/16/20 6:46 PM, Barry Warsaw wrote:
>> That’s what I was going to suggest.  I’m not doing any Debian or Ubuntu work 
>> these days, but Matthias Klose should be watching both lists, and should be 
>> able to handle the Debuntu stack.
>
>> -Barry
>>
>>> On Nov 16, 2020, at 07:45, Miro Hrončok  wrote:
>>>
>>> On 11/16/20 4:10 PM, Paul Ganssle wrote:
> Maybe it would make sense to create a community mailing list for
> packagers?
 That sounds like a good idea to me.
>>> I am following the Linux SIG mailing list. But it's mostly dead.
>>>
>>> https://mail.python.org/archives/list/linux-...@python.org/
>>>
>>> --
>>> Miro Hrončok
>>> --
>>> Phone: +420777974800
>>> IRC: mhroncok
>>> ___
>>> 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/DF3UXOGYRAIOLTRGSNGNSZEKZOUFMXGA/
>>> 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/23R5ZD5ZVA4R73ZTKQWWJR6CDLGRKXJN/
>> 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/MF4J5HIBM37NRZ5I2RSXYLU7PIXVKXO2/
> 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/CYYMZFSJ4IAI3FDJCFNIMFWJLXFNDXJ5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Terry Reedy]

On 11/16/2020 6:14 AM, Mark Shannon wrote:

2. Is the error in the ast matching example, an intentional 
"simplification" or just an oversight?


The example:

```
def simplify(node):
     match node:
     case BinOp(Num(left), '+', Num(right)):
     return Num(left + right)
     case BinOp(left, '+' | '-', Num(0)):
     return simplify(left)
     case UnaryOp('-', UnaryOp('-', item)):
     return simplify(item)
     case _:
     return node

```

is wrong.


This is not 'wrong' because the paper did not specify the signatures or 
definition of BinOp and UnaryOp or a specific module/package of origin. 
 I took these as hypothetical classes in a hypothetical module that 
happens to use what I presume are ast class names.




The correct version is

```
def simplify(node):
     match node:
     case BinOp(Num(left), Add(), Num(right)):
     return Num(left + right)
     case BinOp(left, Add() | Sub(), Num(0)):
     return simplify(left)
     case UnaryOp(USub(), UnaryOp(USub(), item)):
     return simplify(item)
     case _:
     return node
```


Without knowing the signatures of the ast classes, having not worked 
with them as you have, passing instances of an Add class instead of an 
'add' function looks wrong.  How is one Add() different from another? 
For the didactic purpose of the example, this looks worse to me. For me, 
it is harder to read.


--
Terry Jan Reedy

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

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Matthias Klose]

On 11/16/20 6:46 PM, Barry Warsaw wrote:
> That’s what I was going to suggest.  I’m not doing any Debian or Ubuntu work 
> these days, but Matthias Klose should be watching both lists, and should be 
> able to handle the Debuntu stack.

why is this dependency needed?  The tzdata package is marked with Priority
required. See Debian policy 2.5.

Matthias

> -Barry
> 
>> On Nov 16, 2020, at 07:45, Miro Hrončok  wrote:
>>
>> On 11/16/20 4:10 PM, Paul Ganssle wrote:
 Maybe it would make sense to create a community mailing list for
 packagers?
>>> That sounds like a good idea to me.
>>
>> I am following the Linux SIG mailing list. But it's mostly dead.
>>
>> https://mail.python.org/archives/list/linux-...@python.org/
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> 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/DF3UXOGYRAIOLTRGSNGNSZEKZOUFMXGA/
>> 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/23R5ZD5ZVA4R73ZTKQWWJR6CDLGRKXJN/
> 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/MF4J5HIBM37NRZ5I2RSXYLU7PIXVKXO2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2020-11-16 08:54, Glenn Linderman wrote:

On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote:

Jim J. Jewett writes:

  > What advantage can there be in re-using syntax to mean something
  > opposite to what it normally does?

In math, it allows us to write "solve c = f(x) for x".  That doesn't
mean "bind c to the value f(x)", it means exactly the opposite.  No
problem here, I suppose.  So

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

is a way of saying "solve p = Point(x=a, y=b) for a and b".

I understand your distaste for this syntax, but I see no problem
in principle.  It's a problem of programmer habits and the evident
inconsistency with forms like "case Point(x=1, y=2)".  This is
especially true when a or b is already bound.

Indeed. Mathematics never came up with separate symbols for equality and
assignment. Neither did early programming languages. That was a source
of confusion for many programmers.


[snip]

Fortran (1954) used '=' for assignment and '.EQ.' for equality.

Algol (1958) used ':=' for assignment and '=' for equality.
___
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/TGONBSN7ZEVNNGMC5HZMK3BASLGHVILX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Barry Warsaw]

That’s what I was going to suggest.  I’m not doing any Debian or Ubuntu work 
these days, but Matthias Klose should be watching both lists, and should be 
able to handle the Debuntu stack.

-Barry

> On Nov 16, 2020, at 07:45, Miro Hrončok  wrote:
> 
> On 11/16/20 4:10 PM, Paul Ganssle wrote:
>>> Maybe it would make sense to create a community mailing list for
>>> packagers?
>> That sounds like a good idea to me.
> 
> I am following the Linux SIG mailing list. But it's mostly dead.
> 
> https://mail.python.org/archives/list/linux-...@python.org/
> 
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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/DF3UXOGYRAIOLTRGSNGNSZEKZOUFMXGA/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/23R5ZD5ZVA4R73ZTKQWWJR6CDLGRKXJN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Tobias Kohn]

 Hi Mark,

Thank you for your interest and the questions.

1.  This really comes down to how you look at it, or how you define  
pattern matching.  The issue here is that the concept of pattern  
matching has grown into a large and somewhat diverse flock of  
interpretations and implementations (as a side note: interestingly  
enough, some of the only universally agreed-upon standards are to use  
`_` as a wildcard and not to mark names that capture/bind  
values---which are quite exactly the points most fiercely debatted  
here).


Anyway, the paper presents the pattern matching structure we are  
proposing as one of three major variants of pattern matching:

(a)  Matching arguments to parameters in a function call,
(b)  Matching elements to elements in iterable unpacking,
(c)  Matching tree-like data to general patterns in a conditional  
pattern matching structure.


The last one is the subject of the PEP and the paper.  Nonetheless, in  
the first two cases (a) and (b), we find that indeed the computer will  
validate that the data matched the pattern and raise an exception if  
this fails.  This is where this way of looking at it comes from.


2.  Yes, that is indeed a deliberate simplification.  The idea is to  
abstract away from the details of how exactly Python implements  
abstract syntax trees (which I honestly believe are irrelevant for the  
sake of the entire narrative).  Moreover, using strings here allows us  
to exemplify the literal patterns, rather only showcasing only the  
constructor/class pattern.


Essentially, this is a question of making the most out of the little  
space available.


Since you have addressed this email to me directly, I would like to  
take this opportunity and briefly stress that this paper really grew  
out of a team effort.  While I might have been the one pushing for an  
academic publication, the DLS'20 paper represents the input and ideas  
of all the authors, as well as the long discussions we had.  Of  
course, I am happy to answer any questions about the paper, but it  
would be wrong to see me as the one person behind it.


Cheers,
Tobias

Quoting Mark Shannon :


Hi Tobias,

A couple of questions about the DLS 2020 paper.

1. Why do you use the term "validate" rather than "test" for the  
process of selecting a match?


It seems to me, that this is a test, not a validation, as no  
exception is raised if a case doesn't match.


2. Is the error in the ast matching example, an intentional  
"simplification" or just an oversight?


The example:

```
def simplify(node):
   match node:
       case BinOp(Num(left), '+', Num(right)):
           return Num(left + right)
       case BinOp(left, '+' | '-', Num(0)):
           return simplify(left)
       case UnaryOp('-', UnaryOp('-', item)):
           return simplify(item)
       case _:
           return node

```

is wrong.

The correct version is

```
def simplify(node):
   match node:
       case BinOp(Num(left), Add(), Num(right)):
           return Num(left + right)
       case BinOp(left, Add() | Sub(), Num(0)):
           return simplify(left)
       case UnaryOp(USub(), UnaryOp(USub(), item)):
           return simplify(item)
       case _:
           return node
```

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

[Python-Dev] Re: The semantics of pattern matching for Python

[Guido van Rossum]

Thanks Mark, this is a helpful and valuable contribution.

I will try to understand and review it in the coming weeks (there is no
hurry since the decision is up to the next SC) but I encourage you to just
put it in PEP form and check it into the PEP repo.

Because I only skimmed very briefly, I don't have an answer to one
question: does your PEP also define a precise mapping from the PEP 634
syntax to your "desugared" syntax? I think that ought to be part of your
PEP.

--Guido

On Mon, Nov 16, 2020 at 6:41 AM Mark Shannon  wrote:

> Hi everyone,
>
> There has been much discussion on the syntax of pattern matching for
> Python (in case you hadn't noticed ;)
>
> Unfortunately the semantics seem to have been somewhat overlooked.
> What pattern matching actually does seems at least as important as the
> syntax.
>
>
> I believe that a pattern matching implementation must have the following
> properties:
>
> * The semantics must be precisely defined.
> * It must be implemented efficiently.
> * Failed matches must not pollute the enclosing namespace.
> * Objects should be able determine which patterns they match.
> * It should be able to handle erroneous patterns, beyond just syntax
> errors.
>
> PEP 634 and PEP 642 don't have *any* of these properties.
>
>
> I've written up a document to specify a possible semantics of pattern
> matching for Python that has the above properties, and includes reasons
> why they are necessary.
>
>
> https://github.com/markshannon/pattern-matching/blob/master/precise_semantics.rst
>
> It's in the format of a PEP, but it isn't a complete PEP as it lacks
> surface syntax.
>
> Please, let me know what you think.
>
> 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/BTPODVYLPKY5IHWFKYQJICONTNTRNDB2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Filipe Laíns]

On Mon, 2020-11-16 at 09:32 -0500, Paul Ganssle wrote:
 
Hi all,
 
 One part of PEP 615 (IANA time zones) that I expected to be easily
overlooked (a point about which I seem to have been right) is the
recommendation that starting with Python 3.9, distros should add a
dependency on the system time zone data to the Python package. Quoting
the PEP:
 
 
> > Python distributors are encouraged to ensure that time zone data is
> installed alongside Python whenever possible (e.g. by declaring
> tzdata as a dependency for the python package).
>  
 
https://www.python.org/dev/peps/pep-0615/#system-time-zone-information
 
I am not sure what is the best way to reach the largest number of
distro packagers to suggest that they add a dependency on tzdata for
Python 3.9+, so I figured I'd send a message here. If you know a distro
packager who does not follow this list, or you use a distro that
doesn't have a dependency on tzdata for Python 3.9, please forward this
e-mail to them and/or open a bug on their issue tracker.
 
 So far I know conda-forge got the dependency right from the first
Python 3.9 release, Fedora has plans to fix this, and Christian Heimes
has opened a bug on the Ubuntu launchpad for this. I will figure out
how best to notify Arch Linux and do that (since that's the distro I
use).
 
 I suspect this will be most important for distros that are heavily
used in containers, since tzdata is a common enough dependency that
it's likely to be satisfied accidentally in most full-featured user
environments anyway.
 
 Thanks!
 
 Paul
 
 
P.S. If there's a mailing list or other community for Python distro
packagers, please let me know, because I often find that we're making
decisions that affect them that they don't hear about until way down
the line. I'd love to have an easy way to keep them in the loop.

Hi,

In Arch Linux, tzdata is a dependency of glibc, which is part of the
base[1] package that should be present on every installation. So, there
is no action necessary :)
We could make it an explicit dependency, but that it not necessarily
required, it is up to the maintainer, whom I have notified.

I would say the best approach to reach distro packages is to open a bug
in their issue tracker, or to reach them via mailing list. Some of them
have specific mailing lists for Python, Fedora has python-devel[2].

Maybe it would make sense to create a community mailing list for
packagers?

I would also suggest to in the future maybe have a "For packagers"
section, or similar, in the release notes. I don't think right now
there is any reasonable way packagers could have known about this new
dependency unless they are involved with the Python upstream. All the
current changelog does is link to PEP 615, where that information is
present, but it has no mention of new dependencies.

Please let me know if I've overlooked something :P

[1] https://www.archlinux.org/packages/core/any/base/
[2] 
https://lists.fedoraproject.org/archives/list/python-devel%40lists.fedoraproject.org/

Cheers,
Filipe Laíns


signature.asc
Description: This is a digitally signed message part
___
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/NRAK5GRLCMYGRK4KGJSCXASYNCZ5PZWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Miro Hrončok]

On 11/16/20 4:10 PM, Paul Ganssle wrote:

Maybe it would make sense to create a community mailing list for
packagers?

That sounds like a good idea to me.


I am following the Linux SIG mailing list. But it's mostly dead.

https://mail.python.org/archives/list/linux-...@python.org/

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/DF3UXOGYRAIOLTRGSNGNSZEKZOUFMXGA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Paul Ganssle]

On 11/16/20 9:57 AM, Filipe Laíns wrote:
> In Arch Linux, tzdata is a dependency of glibc, which is part of the
> base[1] package that should be present on every installation. So, there
> is no action necessary :)
> We could make it an explicit dependency, but that it not necessarily
> required, it is up to the maintainer, whom I have notified.

I opened a bug on the tracker including a patch:
https://bugs.archlinux.org/task/68642?project=1&string=python

I do think it makes sense to make it a direct dependency, since I
personally worry that transitive dependencies may be fragile (and even
if the transitive dependency is rock-solid, it doesn't hurt anything for
it to exist — plus it gives you metadata about what projects are using
what packages, for purposes of notifying or looking for issues). That
said, it's obviously up to y'all.

There's actually another thing that is probably of interest to distro
packagers, which is that zoneinfo includes a compile-time configuration
option:
https://docs.python.org/3/library/zoneinfo.html#zoneinfo-data-compile-time-config

By default we don't know where the zoneinfo will be deployed, so we use
a set of locations where it's commonly deployed. Since distro packagers
know exactly where it is deployed, they can use the `--with-tzpath`
configuration option to specify it at build time, to make the lookup
that much faster and more accurate.

> I would say the best approach to reach distro packages is to open a bug
> in their issue tracker, or to reach them via mailing list. Some of them
> have specific mailing lists for Python, Fedora has python-devel[2].

Yeah, I was mainly looking for a way to contact all of them at once,
since it doesn't scale very well for me to open bugs on the trackers of
every distributor. I can open bugs for my distro and distros that I care
about, but even that can be pretty duplicative.

> Maybe it would make sense to create a community mailing list for
> packagers?
That sounds like a good idea to me.
> I would also suggest to in the future maybe have a "For packagers"
> section, or similar, in the release notes. I don't think right now
> there is any reasonable way packagers could have known about this new
> dependency unless they are involved with the Python upstream. All the
> current changelog does is link to PEP 615, where that information is
> present, but it has no mention of new dependencies.
This also seems like a good idea to me (though I'm not entirely sure how
often packagers are impacted by changes to CPython — zoneinfo may have
been an unusual case).

Best,
Paul



signature.asc
Description: OpenPGP digital signature
___
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/74KJJM6ZGHVV2RADCTZLVAKY7VO5KIG2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

[Christian Heimes]

On 16/11/2020 15.32, Paul Ganssle wrote:
> Hi all,
> 
> One part of PEP 615 (IANA time zones) that I expected to be easily
> overlooked (a point about which I seem to have been right) is the
> recommendation that starting with Python 3.9, distros should add a
> dependency on the system time zone data to the Python package. Quoting
> the PEP:
> 
>> Python distributors are encouraged to ensure that time zone data is
>> installed alongside Python whenever possible (e.g. by declaring tzdata
>> as a dependency for the python package).
> 
> https://www.python.org/dev/peps/pep-0615/#system-time-zone-information
> 
> I am not sure what is the best way to reach the largest number of distro
> packagers to suggest that they add a dependency on tzdata for Python
> 3.9+, so I figured I'd send a message here. If you know a distro
> packager who does not follow this list, or you use a distro that doesn't
> have a dependency on tzdata for Python 3.9, please forward this e-mail
> to them and/or open a bug on their issue tracker.
> 
> So far I know conda-forge got the dependency right from the first Python
> 3.9 release, Fedora has plans to fix this
> , and
> Christian Heimes has opened a bug on the Ubuntu launchpad
>  for
> this. I will figure out how best to notify Arch Linux and do that (since
> that's the distro I use).
> 
> I suspect this will be most important for distros that are heavily used
> in containers, since tzdata is a common enough dependency that it's
> likely to be satisfied accidentally in most full-featured user
> environments anyway.
> 
> Thanks!
> 
> Paul
> 
> P.S. If there's a mailing list or other community for Python distro
> packagers, please let me know, because I often find that we're making
> decisions that affect them that they don't hear about until way down the
> line. I'd love to have an easy way to keep them in the loop.

Thanks Paul,

would it make sense to add a packaging section to our documentation or
to write an informational PEP? There is already PEP 394, which defines
the "python" command on Unix-like systems. A new informational PEP could
1) assist packagers with best practices, 2) state how the CPython core
team envisions packaging of Python on Unix distributions.

After all there are more dependencies than "tzdata". Python has
dependencies on /etc/mime.types and system trust store for the ssl
module. Users also have been complaining about usability issues and bugs
caused by downstream patches and packaging decisions (like venv,
distutils, tkinter split into optional packages).

By the way Fedora isn't affected by lack of tzdata database. Fedora's
Python package has a transient dependency on tzdata. The package is
always shipped in Fedora's minimal container images, too. Miro's PR
makes the dependency explicit.

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

[Python-Dev] The semantics of pattern matching for Python

[Mark Shannon]

Hi everyone,

There has been much discussion on the syntax of pattern matching for 
Python (in case you hadn't noticed ;)


Unfortunately the semantics seem to have been somewhat overlooked.
What pattern matching actually does seems at least as important as the 
syntax.



I believe that a pattern matching implementation must have the following 
properties:


* The semantics must be precisely defined.
* It must be implemented efficiently.
* Failed matches must not pollute the enclosing namespace.
* Objects should be able determine which patterns they match.
* It should be able to handle erroneous patterns, beyond just syntax errors.

PEP 634 and PEP 642 don't have *any* of these properties.


I've written up a document to specify a possible semantics of pattern 
matching for Python that has the above properties, and includes reasons 
why they are necessary.


https://github.com/markshannon/pattern-matching/blob/master/precise_semantics.rst

It's in the format of a PEP, but it isn't a complete PEP as it lacks 
surface syntax.


Please, let me know what you think.

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

[Python-Dev] Distro packagers: PEP 615 and the tzdata dependency

[Paul Ganssle]

Hi all,

One part of PEP 615 (IANA time zones) that I expected to be easily
overlooked (a point about which I seem to have been right) is the
recommendation that starting with Python 3.9, distros should add a
dependency on the system time zone data to the Python package. Quoting
the PEP:

> Python distributors are encouraged to ensure that time zone data is
> installed alongside Python whenever possible (e.g. by declaring tzdata
> as a dependency for the python package).

https://www.python.org/dev/peps/pep-0615/#system-time-zone-information

I am not sure what is the best way to reach the largest number of distro
packagers to suggest that they add a dependency on tzdata for Python
3.9+, so I figured I'd send a message here. If you know a distro
packager who does not follow this list, or you use a distro that doesn't
have a dependency on tzdata for Python 3.9, please forward this e-mail
to them and/or open a bug on their issue tracker.

So far I know conda-forge got the dependency right from the first Python
3.9 release, Fedora has plans to fix this
, and
Christian Heimes has opened a bug on the Ubuntu launchpad
 for
this. I will figure out how best to notify Arch Linux and do that (since
that's the distro I use).

I suspect this will be most important for distros that are heavily used
in containers, since tzdata is a common enough dependency that it's
likely to be satisfied accidentally in most full-featured user
environments anyway.

Thanks!

Paul

P.S. If there's a mailing list or other community for Python distro
packagers, please let me know, because I often find that we're making
decisions that affect them that they don't hear about until way down the
line. I'd love to have an easy way to keep them in the loop.

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

[Python-Dev] Questions about about the DLS 2020

[Mark Shannon]

Hi Tobias,

A couple of questions about the DLS 2020 paper.

1. Why do you use the term "validate" rather than "test" for the process 
of selecting a match?


It seems to me, that this is a test, not a validation, as no exception 
is raised if a case doesn't match.



2. Is the error in the ast matching example, an intentional 
"simplification" or just an oversight?


The example:

```
def simplify(node):
match node:
case BinOp(Num(left), '+', Num(right)):
return Num(left + right)
case BinOp(left, '+' | '-', Num(0)):
return simplify(left)
case UnaryOp('-', UnaryOp('-', item)):
return simplify(item)
case _:
return node

```

is wrong.

The correct version is

```
def simplify(node):
match node:
case BinOp(Num(left), Add(), Num(right)):
return Num(left + right)
case BinOp(left, Add() | Sub(), Num(0)):
return simplify(left)
case UnaryOp(USub(), UnaryOp(USub(), item)):
return simplify(item)
case _:
return node
```

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/ETZGYRCF4DR6RJXTHGXIRZXINXJ76J2D/
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/15/2020 11:18 PM, Stephen J. Turnbull wrote:

Jim J. Jewett writes:

  > What advantage can there be in re-using syntax to mean something
  > opposite to what it normally does?

In math, it allows us to write "solve c = f(x) for x".  That doesn't
mean "bind c to the value f(x)", it means exactly the opposite.  No
problem here, I suppose.  So

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

is a way of saying "solve p = Point(x=a, y=b) for a and b".

I understand your distaste for this syntax, but I see no problem
in principle.  It's a problem of programmer habits and the evident
inconsistency with forms like "case Point(x=1, y=2)".  This is
especially true when a or b is already bound.
Indeed. Mathematics never came up with separate symbols for equality and 
assignment. Neither did early programming languages. That was a source 
of confusion for many programmers.


Then someone invented == for equality comparison, and = for assignment, 
or alternately := for assignment and = for equality comparison.  Python 
now has the first three, many other languages only have one of the pairs.


This reduced the confusion and resulting bugs, although some still 
happen. Linters help avoid them, and even some compilers emit warnings 
for possibly misused operators of those pairs.


In mathematics, equality might be written a = b or b = a, transitively 
irrelevant.


But I have never seen assignment in mathematics be anything but var = 
value, as in
"let x = 3"  or "let x = ". Maybe I'm just 
uninformed regarding current practice, but I do have a degree in 
mathematics, albeit somewhat dated at this point.


So I also have a distaste for any syntax that puts an assignment target 
on the right, it seems like a step toward reintroducing confusion and 
bugs. The pattern match operator seems complex enough without 
(re-)introducing confusion regarding assignment operators.


In your example "solve c = f(x) for x", that is not an assignment 
operator, but an equality comparison operator in an equation. Although I 
know a few exist, I'm not familiar with programs that do symbolic 
algebra, to know how they notate such instructions: most programming 
language do not do symbolic manipulations.  But note that your example 
is wordier than "let c = f(x)" which would be an assignment operation. 
And note that it _needs to be wordier_ to convey the proper mathematical 
semantics. At least, it did back when I was in math classes.


Just because something is syntactically unambiguous, doesn't mean it 
makes a good user interface.

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