[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

[Guido van Rossum]

On Tue, Feb 9, 2021 at 7:11 AM Ethan Furman  wrote:

>
>  >> Where possible, should we retroactively make existing
>  >> keywords contextual?
>  >
>  > The benefit of contextual keywords is being able to choose popular
> method/function/variable names as new keywords
>  > without a disruptive deprecation and migration process. That benefit
> doesn't apply to existing keywords.
>
> No, but it would have the benefit of allowing existing keywords to be
> reused where it makes sense; a recent example I
> came across is the Tcl/Tk interface -- Tk has a method named `raise`, but
> it has to be renamed to tkraise because of the
> keyword clash (it's also given a `lift` alias).
>

This is a reasonable idea, with definite pros and cons. I recommend
starting a separate thread about that.

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

___
python-committers mailing list -- python-committers@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-committers@python.org/message/6BDF4ECV45OTMVJPZMJ3ILARMGONAZKE/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

[Ethan Furman]

On 2/8/21 3:02 PM, Nick Coghlan wrote:
> On Tue, 9 Feb 2021, 8:18 am Terry Reedy wrote:

>> The one thing I think needs to be discussed and not been much, at least
>> not publicly that I have seen, is whether we really want to go down the
>> road of contextual keywords.  There are some negatives as well as
>> positives.  Just because the new parser makes them possible does not
>> mean we should.  Do we really want to see 'match match:' or 'case
>> match...', etc?
>
> As a hard keyword, the existence of "re.match()" would have almost certainly
> resulted in immediate rejection of the PEP.
>
>> Where possible, should we retroactively make existing
>> keywords contextual?
>
> The benefit of contextual keywords is being able to choose popular 
method/function/variable names as new keywords
> without a disruptive deprecation and migration process. That benefit doesn't 
apply to existing keywords.

No, but it would have the benefit of allowing existing keywords to be reused where it makes sense; a recent example I 
came across is the Tcl/Tk interface -- Tk has a method named `raise`, but it has to be renamed to tkraise because of the 
keyword clash (it's also given a `lift` alias).


--
~Ethan~
___
python-committers mailing list -- python-committers@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-committers@python.org/message/KFFLRVYOLQE2UBFJGK7KGVJJTERAN2QI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

[Nick Coghlan]

On Tue, 9 Feb 2021, 8:18 am Terry Reedy,  wrote:

>
> The one thing I think needs to be discussed and not been much, at least
> not publicly that I have seen, is whether we really want to go down the
> road of contextual keywords.  There are some negatives as well as
> positives.  Just because the new parser makes them possible does not
> mean we should.  Do we really want to see 'match match:' or 'case
> match...', etc?


As a hard keyword, the existence of "re.match()" would have almost
certainly resulted in immediate rejection of the PEP.


Where possible, should we retroactively make existing
> keywords contextual?
>

The benefit of contextual keywords is being able to choose popular
method/function/variable names as new keywords without a disruptive
deprecation and migration process. That benefit doesn't apply to existing
keywords.

Cheers,
Nick.




>
___
python-committers mailing list -- python-committers@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-committers@python.org/message/RBLAPUDMUJ4IMTQA2PWUYGGEU45JH62P/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

[Nick Coghlan]

On Tue, 9 Feb 2021, 6:21 am Python Steering Council, <
steering-coun...@python.org> wrote:

> After much deliberation, the Python Steering Council is happy to announce
> that we have chosen to accept PEP 634, and its companion PEPs 635 and 636,
> collectively known as the Pattern Matching PEPs. We acknowledge that
> Pattern Matching is an extensive change to Python and that reaching
> consensus across the entire community is close to impossible.  Different
> people have reservations or concerns around different aspects of the
> semantics and the syntax (as does the Steering Council). In spite of this,
> after much deliberation, reviewing all conversations around these PEPs, as
> well as competing proposals and existing poll results, and after several
> in-person discussions with the PEP authors, we are confident that Pattern
> Matching as specified in PEP 634, et al, will be a great addition to the
> Python language.


Thank you for resolving this discussion - I'm sure it wasn't an easy
decision.

Obviously I think we're going to find things to regret in the way name
binding works in class and mapping patterns, but I also think using "_ as
name" as an explanatory tool is likely to cover most of them.

I'll also consider submitting a PEP *adding* explicit patterns to the
implicit ones, rather than proposing to replace them, so the handling of
different kinds of bare expressions can be readily explained as syntactic
shorthand for more explicit operations rather than the shorthand being the
only available spelling.

I won't do that until after helping with the review of the main PEP 634
implementation, though.

Cheers,
Nick.


>
>
>
___
python-committers mailing list -- python-committers@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-committers@python.org/message/OMXOT2NCMJBJBLFLMHRZDSIHN6Z7CEDT/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

[Terry Reedy]

On 2/8/2021 3:07 PM, Python Steering Council wrote:

After much deliberation, the Python Steering Council is happy to announce that 
we have chosen to accept PEP 634, and its companion PEPs 635 and 636, 
collectively known as the Pattern Matching PEPs.


Thank you for your collective time and efforts.  I agree with preferring 
634 to the alternatives.  I don't know what I would have decided after 
the additional discussion you all have had.  I do think that for a big 
addition like this, a collective decision is better than one person 
deciding (including for the one person).



We also recognize that such a large new feature needs to be accompanied by 
comprehensive documentation and specification, both in the tutorial section of 
the documentation and in the language reference. We consider that the presence 
of such high-quality documentation must be present on the first release of 
Python 3.10, and therefore its absence should be considered a release blocker.  
We do not consider the PEPs or any possible external documentation to be 
sufficient.


I agree and appreciate this.  There have been new features release 
without adequate documentation.  This requirement means that you had to 
decide now or very soon or likely put this off to 3.11.


The one thing I think needs to be discussed and not been much, at least 
not publicly that I have seen, is whether we really want to go down the 
road of contextual keywords.  There are some negatives as well as 
positives.  Just because the new parser makes them possible does not 
mean we should.  Do we really want to see 'match match:' or 'case 
match...', etc?  Where possible, should we retroactively make existing 
keywords contextual?


This is really independent from the resst of this PEP since we could do 
the traditional thing of deprecate non-keyword uses of 'match' and 
'case' and require a __future__ import for immediate use thereof.


Terry J. Reedy
___
python-committers mailing list -- python-committers@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-committers@python.org/message/YLPTPUQPG5JCOE7ICEMGASNGL4M3LGW7/
Code of Conduct: https://www.python.org/psf/codeofconduct/