[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rob Cliffe via Python-Dev]

Welcome to python-dev, Rik!  Of course you can email to this list.

On 30/07/2020 14:30, Rik de Kort via Python-Dev wrote:


I think adding the Walrus operator is trying to solve a problem that 
doesn't exist. Compare the example from the PEP:

    [snip]

 case (x, y, z):

[snip]


To the one without:

[snip]

 case (x := _, y := _, z := _):
It's a lot more typing, it's a lot more ugly, and I'd argue it's not 
any more explicit than the earlier one.


The debate is still going on as to whether "capture" variables should be 
marked, and if so whether with the walrus operator or in some other way, 
and "var := _" wouldn't be my personal preference. However,


case (x := _, y := _, z := _):

*is* more explicit, because it explicitly says that x, y and z are 
variables that should capture (i.e. be bound to) whatever values are 
found.  Contrast this with say


case (x := _, y := _, z):

which says that z contains a value to be *matched*, and if such a match is 
found, x and y should capture the relevant values.

Best wishes
Rob Cliffe

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rob Cliffe via Python-Dev]

On 03/08/2020 17:37, MRAB wrote:

[snip]
A thought occurred to me. By default, the current rules of the PEP 
could apply, but why not allow prefixing with "as" for a capture and 
"is" for a value?


Yes, I know, comparison of the values is not by identity, but "is" is 
a short keyword that already exists and matches up with "as".



What about 'match'?  Not as short, but fairly intuitive:

    case (x, y, match Z):
        print(f'A point whose z-coordinate equals {Z}')
___
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/TXMR3IVHSKOLMNGUGSGLJSULY4FFHSBW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Pay for PR review and merging for VxWorks RTOS

[Xin, Peixing]

Hi, Python developers:

Anyone interested in PR review and merging for VxWorks RTOS? We can give a 
proper pay for that. Contact me if you have interest.

Thanks,
Peixing

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Ethan Furman]

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Antoine Pitrou]

On Wed, 5 Aug 2020 09:47:30 -0700
Ethan Furman  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-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/NJIBNHGRF3O24LVJYMHTXZ32ENKEVIVD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern matching (alternative to PEP 622)

[Eric Nieuwland]

> On 4 Aug 2020, at 14:38, Koos Zevenhoven wrote:
> 
> Hi everyone,
> 
> [ … analysis of design goals and possible solutions, including … ]
> 
> Point3D(x=pi, y=SIX, z=value)

It suddenly struck me that

Point3D(x=pi, y=SIX, z into value)

would quite accurately describe what is being established here.

> [ … goes on … ]
> 
>  matches 
> 
> and that would evaluate to a boolean-like value.

Yes. I’d like that as it separates functionality (pattern matching) from the 
control structure (match statement).

> [ … ]
> 
> Similarly, also
>   point matches main_diagonal_point(pos?)
> should only match if x == y == z — and then bind that value to pos.
> However, one might expect to be able to write the same thing inline as
>   point matches Point3D(pos?, pos?, pos?)
> , so based on that, multiple occurrences of the same binding target should
> ensure equality.
> 
> 
> What about wildcards? If ? were the wildcard, that would mean that
>   point matches main_diagonal_point(?)
> should NOT mean the same as
>   point matches Point3D(?,?,?)
> 
> [ … ]

Clever observations!

> —Koos


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

[Python-Dev] Re: Python Documentation, Python language improvement, and productive discussion

[Dominic Davis-Foster]

Hi Carol,

I was wondering if you've been able to set up the workgroup yet? I'd certainly 
be interested in participating the there's an opportunity.


Stay safe

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

On Wed, Aug 5, 2020 at 9:48 AM Ethan Furman  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?)*

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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Barry Warsaw]

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

-Barry

> On Aug 5, 2020, at 09:47, Ethan Furman  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-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/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/
> 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/CVYGPSODOHTLEGPRM4EI5GTMR6PHSZLF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Luciano Ramalho]

On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn  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 :
>
>
>
> 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-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/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-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/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Robert White]

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  wrote:

> On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn  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 :
> >
> >
> >
> > 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-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/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-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/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-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/PZMWDYELYFYRDV3TZ3B4KLEPCJPN4JFB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Larry Hastings]

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 > wrote:


On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn mailto:ko...@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 mailto:la...@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-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/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-le...@python.org

https://mail.python.org/mailman3/lists/python-dev.python.org/
Messag

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Luciano Ramalho]

On Wed, Aug 5, 2020 at 8:14 PM Larry Hastings  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  wrote:
>>
>> On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn  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 :
>> >
>> >
>> >
>> > 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-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/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-le...@python.org
>> https://mail.python.org/mailman3/lists

[Python-Dev] Re: Pay for PR review and merging for VxWorks RTOS

[Kyle Stanley]

What exactly does the PR involve? Is it a relatively simple compatibility
patch or something that adds significant amounts of platform-specific code?
The former can be reviewed (and potentially merged) by any core dev
knowledgeable in the areas being changed, but the latter requires long-term
support for the platform.

In order to provide support for a new platform that we don't presently have
support for in CPython, it requires the following:

1) An existing core developer willing to provide long-term support for the
platform. Alternatively, someone else can be granted commit privileges, for
the purpose of maintaining that platform and fixing any issues that come up
in that CI that are specific to it. However, this is done on a case-by-case
basis, as it still requires a decent amount of trust with that individual.

2) A stable buildbot provided, to test against new changes made to CPython.

The purpose of the above is to ensure that any substantial
platform-specific code added to CPython receives proper care; this is
opposed to a large addition of new code for a platform that has nobody to
take care of it when issues come up. Especially as a group of mostly
volunteers (and those paid by their employers to contribute), the latter
wouldn't be sustainable. I personally think it would be fantastic to have
official support for real-time OSs in CPython, but in this ecosystem, it
requires being able to place trust in someone that's willing and adequately
proficient in the related areas to provide long-term support for them.

For more details, see PEP 11:
https://www.python.org/dev/peps/pep-0011/#supporting-platforms.


On Wed, Aug 5, 2020 at 7:44 AM Xin, Peixing 
wrote:

> Hi, Python developers:
>
>
>
> Anyone interested in PR review and merging for VxWorks RTOS? We can give a
> proper pay for that. Contact me if you have interest.
>
>
>
> Thanks,
>
> Peixing
>
>
> ___
> 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/HATTYX3BWEIPVVUL7FMSNSCFYOBPS6OD/
> 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/ZT2RA7KT7AFMAXTKDQGQOQ6TCUXWE5QT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pay for PR review and merging for VxWorks RTOS

[Xin, Peixing]

Hi, Stanley:

Thanks for your comments.

Almost all the patches are simple compatibility patch. But the subprocess 
module is an exception. Like windows, VxWorks have no fork/exec API provided. 
Instead, VxWorks uses rtpSpawn() to spawn a new process. So we have to 
implement VxWorks’ own extension modules to support subprocess module. However, 
this is not significant amount of codes, just around 500 lines of C codes. 
Hopes any core dev could help to review and merge the simple compatibility 
patches. If I can be granted the commit privileges, that will be great. To 
ensure the quality, I will get the patches reviewed enough well before merging.
For long term support for VxWorks RTOS, I am an engineer from Wind River. Wind 
River is willing to officially provide the support and I am willing to be the 
maintainer. Buildbot is also not a problem. Once the patches have been merging 
done, we will connect the buildbot for VxWorks.

Thanks,
Peixing

From: Kyle Stanley 
Sent: Thursday, August 6, 2020 9:27 AM
To: Xin, Peixing 
Cc: python-dev@python.org; Meng, Bin 
Subject: Re: [Python-Dev] Pay for PR review and merging for VxWorks RTOS

What exactly does the PR involve? Is it a relatively simple compatibility patch 
or something that adds significant amounts of platform-specific code? The 
former can be reviewed (and potentially merged) by any core dev knowledgeable 
in the areas being changed, but the latter requires long-term support for the 
platform.

In order to provide support for a new platform that we don't presently have 
support for in CPython, it requires the following:

1) An existing core developer willing to provide long-term support for the 
platform. Alternatively, someone else can be granted commit privileges, for the 
purpose of maintaining that platform and fixing any issues that come up in that 
CI that are specific to it. However, this is done on a case-by-case basis, as 
it still requires a decent amount of trust with that individual.

2) A stable buildbot provided, to test against new changes made to CPython.

The purpose of the above is to ensure that any substantial platform-specific 
code added to CPython receives proper care; this is opposed to a large addition 
of new code for a platform that has nobody to take care of it when issues come 
up. Especially as a group of mostly volunteers (and those paid by their 
employers to contribute), the latter wouldn't be sustainable. I personally 
think it would be fantastic to have official support for real-time OSs in 
CPython, but in this ecosystem, it requires being able to place trust in 
someone that's willing and adequately proficient in the related areas to 
provide long-term support for them.

For more details, see PEP 11: 
https://www.python.org/dev/peps/pep-0011/#supporting-platforms.


On Wed, Aug 5, 2020 at 7:44 AM Xin, Peixing 
mailto:peixing@windriver.com>> wrote:
Hi, Python developers:

Anyone interested in PR review and merging for VxWorks RTOS? We can give a 
proper pay for that. Contact me if you have interest.

Thanks,
Peixing

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