Mailing List Archive

PEP 622 is already on the SC’s agenda for review.

-Barry

> On Aug 5, 2020, at 09:47, Ethan Furman <ethan@stoneleaf.us> wrote:
>
> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:
>
>> The debate is still going on as to whether "capture" variables should be marked...
> I don't think the PEP authors are debating it any more. Quite frankly, I wish they would present to the SC and get accepted so we can get Pattern Matching added to 3.10. :)
>
> --
> ~Ethan~
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/
> Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 5 Aug 2020 09:47:30 -0700
Ethan Furman <ethan@stoneleaf.us> wrote:
> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:
>
> > The debate is still going on as to whether "capture" variables should be
> > marked...
> I don't think the PEP authors are debating it any more.

That would be a pity. Readability and ease of understanding should
trump conciseness.

Regards

Antoine.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/NJIBNHGRF3O24LVJYMHTXZ32ENKEVIVD/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Aug 5, 2020 at 9:48 AM Ethan Furman <ethan@stoneleaf.us> wrote:

> I don't think the PEP authors are debating it any more. Quite frankly,
> I wish they would present to the SC and get accepted so we can get
> Pattern Matching added to 3.10. :)
>

We did, a few weeks ago, and the SC is already reviewing it. That's all I
know.

--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@tobiaskohn.ch> wrote:
> And experience from other programming languages who took the leap to having
> pattern matching shows that it quickly becomes a quite intuitive and easy to use feature.

The languages I know about that have pattern matching had it from the
start as a core feature.

I am curious to learn about languages that adopted pattern matching
later in their evolution.

Cheers,

Luciano


>
> Cheers,
> Tobias
>
> P.S. Please excuse my late reply; I am currently on vacation.
>
>
>
> Quoting Larry Hastings <larry@hastings.org>:
>
>
>
> On 7/31/20 12:36 AM, Tobias Kohn wrote:
>
> And since pattern matching is really
> a new feature to be introduced to Python, a feature that can
> be seen in different lights, there is no 'Python-Programmer
> intuition' that would apply in this case.
>
> It's not fair to say "intuition doesn't apply because it's new syntax". There are plenty of examples of intuition serving a Python programmer well when encountering new syntax. A Python programmer's intuition is informed by existing syntax and conventions in the language. When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.
>
> Take for example list comprehensions. Python 1 programmers hadn't seen
>
> a = [x for x in y]
>
> But they knew what square brackets meant in that context, it meant "creates a new list". And they knew what "for x in y" meant, that meant iteration. Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and set and dict comprehensions they'd surely intuit what those did immediately.
>
> The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly different semantics. For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual semantics and behavior is very different. Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or undotted-identifiers when defining a key. Add the "capture pattern" to both of these, and a Python programmer's intuition about what this syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.
>
> Cheers,
>
>
>
> /arry
>
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/2VRPDW4EE243QT3QNNCO7XFZYZGIY6N3/
> 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-leave@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/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/
Code of Conduct: http://python.org/psf/codeofconduct/

Off the top of my head for recently happened and fairly mainstream language:
C# added it in 8.0
https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0

On Wed, Aug 5, 2020 at 3:33 PM Luciano Ramalho <luciano@ramalho.org> wrote:

> On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@tobiaskohn.ch> wrote:
> > And experience from other programming languages who took the leap to
> having
> > pattern matching shows that it quickly becomes a quite intuitive and
> easy to use feature.
>
> The languages I know about that have pattern matching had it from the
> start as a core feature.
>
> I am curious to learn about languages that adopted pattern matching
> later in their evolution.
>
> Cheers,
>
> Luciano
>
>
> >
> > Cheers,
> > Tobias
> >
> > P.S. Please excuse my late reply; I am currently on vacation.
> >
> >
> >
> > Quoting Larry Hastings <larry@hastings.org>:
> >
> >
> >
> > On 7/31/20 12:36 AM, Tobias Kohn wrote:
> >
> > And since pattern matching is really
> > a new feature to be introduced to Python, a feature that can
> > be seen in different lights, there is no 'Python-Programmer
> > intuition' that would apply in this case.
> >
> > It's not fair to say "intuition doesn't apply because it's new syntax".
> There are plenty of examples of intuition serving a Python programmer well
> when encountering new syntax. A Python programmer's intuition is informed
> by existing syntax and conventions in the language. When they see a new
> construct, its similarity to existing constructs can make understanding the
> new syntax quite intuitive indeed.
> >
> > Take for example list comprehensions. Python 1 programmers hadn't seen
> >
> > a = [x for x in y]
> >
> > But they knew what square brackets meant in that context, it meant
> "creates a new list". And they knew what "for x in y" meant, that meant
> iteration. Understanding those separate two concepts, a Python 1
> programmer would be well on their way to guessing what the new syntax
> meant--and they'd likely be right. And once they understood list
> comprehensions, the first time they saw generator expressions and set and
> dict comprehensions they'd surely intuit what those did immediately.
> >
> > The non-intuitiveness of PEP 622, as I see it, is that it repurposes
> what looks like existing Python syntax but frequently has wholly different
> semantics. For example, a "class pattern" looks like it's calling a
> function--perhaps instantiating an object?--but the actual semantics and
> behavior is very different. Similarly, a "mapping pattern" looks like it's
> instantiating a dict, but it does something very different, and has
> unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you
> can't use full expressions or undotted-identifiers when defining a key.
> Add the "capture pattern" to both of these, and a Python programmer's
> intuition about what this syntax traditionally does will be of little help
> when encountering a PEP 622 match statement for the first time.
> >
> > Cheers,
> >
> >
> >
> > /arry
> >
> >
> >
> > _______________________________________________
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-leave@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/2VRPDW4EE243QT3QNNCO7XFZYZGIY6N3/
> > 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-leave@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/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

It's interesting to consider how C# did it.  For example, at the same
time they added pattern matching, they also added "discards", which are
(undeclared-only?) variables whose name starts with '_' and whose value
is never retained.  I'm not sure, but I believe the language previously
permitted (and still permits) conventional variables that started with
'_'.  My guess is that that's now discouraged, and new code is
encouraged to only use identifiers starting with '_' as discards.

And, a minor correction: C# added pattern matching (and discards) in
version 7, though they did extend the syntax in version 8.


Cheers,


//arry/

On 8/5/20 2:04 PM, Robert White wrote:
> Off the top of my head for recently happened and fairly mainstream
> language:
> C# added it in 8.0
> https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0
>
> On Wed, Aug 5, 2020 at 3:33 PM Luciano Ramalho <luciano@ramalho.org
> <mailto:luciano@ramalho.org>> wrote:
>
> On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@tobiaskohn.ch
> <mailto:kohnt@tobiaskohn.ch>> wrote:
> > And experience from other programming languages who took the
> leap to having
> > pattern matching shows that it quickly becomes a quite intuitive
> and easy to use feature.
>
> The languages I know about that have pattern matching had it from the
> start as a core feature.
>
> I am curious to learn about languages that adopted pattern matching
> later in their evolution.
>
> Cheers,
>
> Luciano
>
>
> >
> > Cheers,
> > Tobias
> >
> > P.S. Please excuse my late reply; I am currently on vacation.
> >
> >
> >
> > Quoting Larry Hastings <larry@hastings.org
> <mailto:larry@hastings.org>>:
> >
> >
> >
> > On 7/31/20 12:36 AM, Tobias Kohn wrote:
> >
> > And since pattern matching is really
> > a new feature to be introduced to Python, a feature that can
> > be seen in different lights, there is no 'Python-Programmer
> > intuition' that would apply in this case.
> >
> > It's not fair to say "intuition doesn't apply because it's new
> syntax".  There are plenty of examples of intuition serving a
> Python programmer well when encountering new syntax.  A Python
> programmer's intuition is informed by existing syntax and
> conventions in the language.  When they see a new construct, its
> similarity to existing constructs can make understanding the new
> syntax quite intuitive indeed.
> >
> > Take for example list comprehensions.  Python 1 programmers
> hadn't seen
> >
> > a = [x for x in y]
> >
> > But they knew what square brackets meant in that context, it
> meant "creates a new list".  And they knew what "for x in y"
> meant, that meant iteration.  Understanding those separate two
> concepts, a Python 1 programmer would be well on their way to
> guessing what the new syntax meant--and they'd likely be right. 
> And once they understood list comprehensions, the first time they
> saw generator expressions and set and dict comprehensions they'd
> surely intuit what those did immediately.
> >
> > The non-intuitiveness of PEP 622, as I see it, is that it
> repurposes what looks like existing Python syntax but frequently
> has wholly different semantics.  For example, a "class pattern"
> looks like it's calling a function--perhaps instantiating an
> object?--but the actual semantics and behavior is very different. 
> Similarly, a "mapping pattern" looks like it's instantiating a
> dict, but it does something very different, and has unfamiliar and
> seemingly arbitrary rules about what is permitted, e.g. you can't
> use full expressions or undotted-identifiers when defining a key. 
> Add the "capture pattern" to both of these, and a Python
> programmer's intuition about what this syntax traditionally does
> will be of little help when encountering a PEP 622 match statement
> for the first time.
> >
> > Cheers,
> >
> >
> >
> > /arry
> >
> >
> >
> > _______________________________________________
> > Python-Dev mailing list -- python-dev@python.org
> <mailto:python-dev@python.org>
> > To unsubscribe send an email to python-dev-leave@python.org
> <mailto:python-dev-leave@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/2VRPDW4EE243QT3QNNCO7XFZYZGIY6N3/
> > 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
> <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-leave@python.org
> <mailto:python-dev-leave@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/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/PZMWDYELYFYRDV3TZ3B4KLEPCJPN4JFB/
> Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Aug 5, 2020 at 8:14 PM Larry Hastings <larry@hastings.org> wrote:
> It's interesting to consider how C# did it. For example, at the same time they added pattern matching, they also added "discards", which are (undeclared-only?) variables whose name starts with '_' and whose value is never retained. I'm not sure, but I believe the language previously permitted (and still permits) conventional variables that started with '_'. My guess is that that's now discouraged, and new code is encouraged to only use identifiers starting with '_' as discards.
>
> And, a minor correction: C# added pattern matching (and discards) in version 7, though they did extend the syntax in version 8.

Yes, that was my goal when I asked about pattern matching added to a
language after its initial design: maybe we could learn something
about how to adopt this feature gradually instead of all at once.

>
>
> Cheers,
>
>
> /arry
>
> On 8/5/20 2:04 PM, Robert White wrote:
>
> Off the top of my head for recently happened and fairly mainstream language:
> C# added it in 8.0
> https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0
>
> On Wed, Aug 5, 2020 at 3:33 PM Luciano Ramalho <luciano@ramalho.org> wrote:
>>
>> On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@tobiaskohn.ch> wrote:
>> > And experience from other programming languages who took the leap to having
>> > pattern matching shows that it quickly becomes a quite intuitive and easy to use feature.
>>
>> The languages I know about that have pattern matching had it from the
>> start as a core feature.
>>
>> I am curious to learn about languages that adopted pattern matching
>> later in their evolution.
>>
>> Cheers,
>>
>> Luciano
>>
>>
>> >
>> > Cheers,
>> > Tobias
>> >
>> > P.S. Please excuse my late reply; I am currently on vacation.
>> >
>> >
>> >
>> > Quoting Larry Hastings <larry@hastings.org>:
>> >
>> >
>> >
>> > On 7/31/20 12:36 AM, Tobias Kohn wrote:
>> >
>> > And since pattern matching is really
>> > a new feature to be introduced to Python, a feature that can
>> > be seen in different lights, there is no 'Python-Programmer
>> > intuition' that would apply in this case.
>> >
>> > It's not fair to say "intuition doesn't apply because it's new syntax". There are plenty of examples of intuition serving a Python programmer well when encountering new syntax. A Python programmer's intuition is informed by existing syntax and conventions in the language. When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.
>> >
>> > Take for example list comprehensions. Python 1 programmers hadn't seen
>> >
>> > a = [x for x in y]
>> >
>> > But they knew what square brackets meant in that context, it meant "creates a new list". And they knew what "for x in y" meant, that meant iteration. Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and set and dict comprehensions they'd surely intuit what those did immediately.
>> >
>> > The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly different semantics. For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual semantics and behavior is very different. Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or undotted-identifiers when defining a key. Add the "capture pattern" to both of these, and a Python programmer's intuition about what this syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.
>> >
>> > Cheers,
>> >
>> >
>> >
>> > /arry
>> >
>> >
>> >
>> > _______________________________________________
>> > Python-Dev mailing list -- python-dev@python.org
>> > To unsubscribe send an email to python-dev-leave@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/2VRPDW4EE243QT3QNNCO7XFZYZGIY6N3/
>> > 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-leave@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/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/PZMWDYELYFYRDV3TZ3B4KLEPCJPN4JFB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/CGR7J6B2XH3C5FF5HBJ76VAOEAWIXACH/
> 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-leave@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/JY3P6NRQOISOD6AEYJLITUB5ECDUVSTF/
Code of Conduct: http://python.org/psf/codeofconduct/

Javascript hasn't it yet, but there is an active proposal for it in the
standardization committee: https://github.com/tc39/proposal-pattern-matching


On Wed, 5 Aug 2020 at 21:34, Luciano Ramalho <luciano@ramalho.org> wrote:

> On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@tobiaskohn.ch> wrote:
> > And experience from other programming languages who took the leap to
> having
> > pattern matching shows that it quickly becomes a quite intuitive and
> easy to use feature.
>
> The languages I know about that have pattern matching had it from the
> start as a core feature.
>
> I am curious to learn about languages that adopted pattern matching
> later in their evolution.
>
> Cheers,
>
> Luciano
>
>
> >
> > Cheers,
> > Tobias
> >
> > P.S. Please excuse my late reply; I am currently on vacation.
> >
> >
> >
> > Quoting Larry Hastings <larry@hastings.org>:
> >
> >
> >
> > On 7/31/20 12:36 AM, Tobias Kohn wrote:
> >
> > And since pattern matching is really
> > a new feature to be introduced to Python, a feature that can
> > be seen in different lights, there is no 'Python-Programmer
> > intuition' that would apply in this case.
> >
> > It's not fair to say "intuition doesn't apply because it's new syntax".
> There are plenty of examples of intuition serving a Python programmer well
> when encountering new syntax. A Python programmer's intuition is informed
> by existing syntax and conventions in the language. When they see a new
> construct, its similarity to existing constructs can make understanding the
> new syntax quite intuitive indeed.
> >
> > Take for example list comprehensions. Python 1 programmers hadn't seen
> >
> > a = [x for x in y]
> >
> > But they knew what square brackets meant in that context, it meant
> "creates a new list". And they knew what "for x in y" meant, that meant
> iteration. Understanding those separate two concepts, a Python 1
> programmer would be well on their way to guessing what the new syntax
> meant--and they'd likely be right. And once they understood list
> comprehensions, the first time they saw generator expressions and set and
> dict comprehensions they'd surely intuit what those did immediately.
> >
> > The non-intuitiveness of PEP 622, as I see it, is that it repurposes
> what looks like existing Python syntax but frequently has wholly different
> semantics. For example, a "class pattern" looks like it's calling a
> function--perhaps instantiating an object?--but the actual semantics and
> behavior is very different. Similarly, a "mapping pattern" looks like it's
> instantiating a dict, but it does something very different, and has
> unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you
> can't use full expressions or undotted-identifiers when defining a key.
> Add the "capture pattern" to both of these, and a Python programmer's
> intuition about what this syntax traditionally does will be of little help
> when encountering a PEP 622 match statement for the first time.
> >
> > Cheers,
> >
> >
> >
> > /arry
> >
> >
> >
> > _______________________________________________
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-leave@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/2VRPDW4EE243QT3QNNCO7XFZYZGIY6N3/
> > 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-leave@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/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Hi Barry,

How long do we have to present objections to PEP 622?

I don't feel that the PEP gives adequate prominence to the objections so
far raised, and there are more issues I would like to bring up.

Cheers,
Mark.


On 05/08/2020 5:58 pm, Barry Warsaw wrote:
> PEP 622 is already on the SC’s agenda for review.
>
> -Barry
>
>> On Aug 5, 2020, at 09:47, Ethan Furman <ethan@stoneleaf.us> wrote:
>>
>> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:
>>
>>> The debate is still going on as to whether "capture" variables should be marked...
>> I don't think the PEP authors are debating it any more. Quite frankly, I wish they would present to the SC and get accepted so we can get Pattern Matching added to 3.10. :)
>>
>> --
>> ~Ethan~
>> _______________________________________________
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-leave@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/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/CVYGPSODOHTLEGPRM4EI5GTMR6PHSZLF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/OSDBFZRZFJVSZ5ZBJ6QFRPWEGL2FJCJZ/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Aug 6, 2020 at 3:46 AM Mark Shannon <mark@hotpy.org> wrote:

> Hi Barry,
>
> How long do we have to present objections to PEP 622?
>

We haven't discussed a timeline among ourselves yet (unless it was
discussed at the last meeting which missed ????).


>
> I don't feel that the PEP gives adequate prominence to the objections so
> far raised, and there are more issues I would like to bring up.
>

I don't think we would want to keep pushing out every time someone has more
to say as that would mean this would never end. ???? But I doubt we will be
making a decision next week, so if you can get any comments in between now
and the 17th you will probably get it in before the earliest we will very
optimistically make a decision.

-Brett


>
> Cheers,
> Mark.
>
>
> On 05/08/2020 5:58 pm, Barry Warsaw wrote:
> > PEP 622 is already on the SC’s agenda for review.
> >
> > -Barry
> >
> >> On Aug 5, 2020, at 09:47, Ethan Furman <ethan@stoneleaf.us> wrote:
> >>
> >> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:
> >>
> >>> The debate is still going on as to whether "capture" variables should
> be marked...
> >> I don't think the PEP authors are debating it any more. Quite frankly,
> I wish they would present to the SC and get accepted so we can get Pattern
> Matching added to 3.10. :)
> >>
> >> --
> >> ~Ethan~
> >> _______________________________________________
> >> Python-Dev mailing list -- python-dev@python.org
> >> To unsubscribe send an email to python-dev-leave@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/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> > _______________________________________________
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-leave@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/CVYGPSODOHTLEGPRM4EI5GTMR6PHSZLF/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/OSDBFZRZFJVSZ5ZBJ6QFRPWEGL2FJCJZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Just taking a ride on the thread here,

I made a quick talk on the proposed feature for a local group,
and in the process I refactored a "real world" class I have in a
project, which features a complicated __init__ due having lots
of different, optional, ways to be initialized.

I can tell I liked what could be done -
reducing roughly 60 loc packed with "isinstance" calls,
"if/elif" blocks, temporary, intermediate state variables,
into 25 lines including 10 case-clauses that are very
straightforward to read.

Sorry for whoever would like an example differing much of the
"point2d" examples on the PEP, but the class in question IS geometry
related
and is a Rectangle -


I am not yet testing (neither on the 'normal' if/else version)
_invalid_ arguments - there are a lot of way to pass
conflicting arguments to __init__ - and the if/elif logic
to handle those properly is not in place. The match/case
version for handling these invalid combinations would be
very straight forwad, on the other hand .

(all said, I think I still miss a way to mark variables that
are assigned in the case clauses, just for the record :-) )

Enough cheaptalk - links are here:

tests:
https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356

Branch comparison for the match/case version:
https://github.com/jsbueno/terminedia/compare/patma

You will notice one "real world" pattern that was needed there: as the case
clauses had
to be aware of values spread across different keyword-parameters, I had to
prepend
a "packing" of all function arguments into a mapping to match against.

If I would not care for the function signature, I could just get "**kwargs"
and match against that.



On Thu, 6 Aug 2020 at 14:09, Brett Cannon <brett@python.org> wrote:

>
>
> On Thu, Aug 6, 2020 at 3:46 AM Mark Shannon <mark@hotpy.org> wrote:
>
>> Hi Barry,
>>
>> How long do we have to present objections to PEP 622?
>>
>
> We haven't discussed a timeline among ourselves yet (unless it was
> discussed at the last meeting which missed ????).
>
>
>>
>> I don't feel that the PEP gives adequate prominence to the objections so
>> far raised, and there are more issues I would like to bring up.
>>
>
> I don't think we would want to keep pushing out every time someone has
> more to say as that would mean this would never end. ???? But I doubt we will
> be making a decision next week, so if you can get any comments in between
> now and the 17th you will probably get it in before the earliest we will
> very optimistically make a decision.
>
> -Brett
>
>
>>
>> Cheers,
>> Mark.
>>
>>
>> On 05/08/2020 5:58 pm, Barry Warsaw wrote:
>> > PEP 622 is already on the SC’s agenda for review.
>> >
>> > -Barry
>> >
>> >> On Aug 5, 2020, at 09:47, Ethan Furman <ethan@stoneleaf.us> wrote:
>> >>
>> >> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:
>> >>
>> >>> The debate is still going on as to whether "capture" variables should
>> be marked...
>> >> I don't think the PEP authors are debating it any more. Quite
>> frankly, I wish they would present to the SC and get accepted so we can get
>> Pattern Matching added to 3.10. :)
>> >>
>> >> --
>> >> ~Ethan~
>> >> _______________________________________________
>> >> Python-Dev mailing list -- python-dev@python.org
>> >> To unsubscribe send an email to python-dev-leave@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/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/
>> >> Code of Conduct: http://python.org/psf/codeofconduct/
>> >
>> >
>> > _______________________________________________
>> > Python-Dev mailing list -- python-dev@python.org
>> > To unsubscribe send an email to python-dev-leave@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/CVYGPSODOHTLEGPRM4EI5GTMR6PHSZLF/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>> >
>> _______________________________________________
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-leave@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/OSDBFZRZFJVSZ5ZBJ6QFRPWEGL2FJCJZ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/ESAKYRYV6L6ZMMXO4NTMYOD6OBSOBRQO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

On 07Aug2020 2133, Joao S. O. Bueno wrote:
> Enough cheaptalk - links are here:
>
> tests:
> https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356
>
> Branch comparison for the match/case version:
> https://github.com/jsbueno/terminedia/compare/patma

I haven't been following this thread too closely, but that looks pretty
nice to me. Not obvious enough for me to write my own just from reading
an example, and I'd hesitate before trying to modify it at all, but I
can at least read the pre- and post-conditions more easily than in the
original.

> (all said, I think I still miss a way to mark variables that
> are assigned in the case clauses, just for the record :-) )

Yeah, the implicit variable assignments seem like the most confusing bit
(based solely on looking at just one example). I think I'd be happy
enough just knowing that "kw" matches the pattern, and then manually
extracting individual values from it. (But I guess for that we'd only
need a fancy "if_match(kw, 'expression')" function... hmm...)

Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/AU6YADGMSOYOIPKNKFWFGC5XEEVOYDO7/
Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, 7 Aug 2020 17:33:04 -0300
"Joao S. O. Bueno" <jsbueno@python.org.br> wrote:
>
> Branch comparison for the match/case version:
> https://github.com/jsbueno/terminedia/compare/patma

For me, your example is bonkers from the start. Anyone who thinks

`Rect(left_or_corner1=None, top_or_corner2=None, right=None,
bottom=None, *, width_height=None, width=None, height=None,
center=None)`

is a reasonable constructor signature for a rectangle class needs to be
convinced otherwise, rather than be allowed to find convenient
implementation shortcuts for that signature.

I'll note that there's no checking for superfluous / exclusive
arguments, so apparently I can pass all those arguments at once and the
constructor will happily do what it likes, ignoring half the
arguments I have without telling? WTH?

(and of course, there's no docstring anywhere, so I can only /presume/
this is supposed to be a rectangle class, based on its name)

And as a matter of fact, while the pattern matching implementation is
definitely shorter, it's still unreadable.

I don't know about you, but if I see this during a code review:
```
match kw:
case {"c1": (c1:=(_, _)), "c2": (c2:=(_, _))}: pass
case {"c1": Rect(c1, c2)}: pass
case {"c1": Number(), "c2": Number(), "right": Number(),
"bottom": Number()}:
c1, c2 = (kw["c1"], kw["c2"]), (right, bottom)
case {"c1": (_, _, _, _)}:
c1, c2 = kw["c1"][:2], kw["c1"][2:]
case {"c1": (c1:=(_, _)), "width_height": (_, _)}:
c2 = c1 + V2(width_height)
case {"c1": (c1:=(_, _)), "width": Number(), "height":
Number()}:
c2 = c1 + V2(width, height)
case {"c1": (c1:=(_, _)), "c2": None, "right": Number(),
"bottom": Number()}:
c2 = bottom, right
case {"c1": None, "right": Number(), "bottom": Number(),
"center": (_, _)}:
c1 = 0, 0
c2 = bottom, right
case {"c1": (c2:=(_, _)), "c2": None}:
c1 = 0, 0
```

then I will ask the author to think twice about the fact they're
inflicting pain on their follow contributors by committing write-only
code (in addition to the toxic API design).

So, if the aim of the example was to prove that bad APIs could be
implemented more tersely using pattern matching, then congratulations,
otherwise I'm not impressed at all.

Regards

Antoine.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/4LCLAS5QKWUU4SBVKX2QOLW7XAONMXQQ/
Code of Conduct: http://python.org/psf/codeofconduct/

It would be fantastic if these were expressions rather than statements. Imagine being able to write things like:

```python
@memoized
def fibonacci(n):
match n:
case 0:
(return/yield?) 0
case 1:
1
case _:
fibonacci(n - 2) + fibonacci(n - 1)
```

Obviously this could be written easily with an if statement, and might not be the best example. But I’ve often encountered situations where I wish I had semantics like this.


Jens


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorized use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/PLPOHR623XNAT4ZEQGSRFDKUBTK3PWVK/
Code of Conduct: http://python.org/psf/codeofconduct/