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

2021-02-09 Thread 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/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

2021-02-09 Thread 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6BDF4ECV45OTMVJPZMJ3ILARMGONAZKE/
Code of Conduct: https://www.python.org/psf/codeofconduct/