[Python-Dev] Re: My thoughts on Pattern Matching.

[Nick Coghlan]

On Sat., 7 Nov. 2020, 9:56 am Greg Ewing, 
wrote:

> On 7/11/20 4:03 am, Thomas Wouters wrote:
>
> > It's also why I'm not in favour of PEP 642 and other proposals for
> > solving some of the problems in the Structural Pattern Matching proposal
> > (sigils, etc): it widens the gap instead of closing it.
>
> Does that mean you're against *any* proposal that involves sigils, or
> just PEP 642 in particular?
>
> Also, I'm very confused about why you're against PEP 642. It seems to
> do a good job of meeting your stated goals -- syntax in common between
> unpacking and matching has the same meaning, and the way is left open
> for making them more like each other in the future. Can you elaborate
> on what you don't like about it?


It seems worth noting that many of Thomas's reservations align with my own
about my proposal in PEP 642 (both the original version I published last
week and the updated one I just published today).

Certainly my *goal* is to address those key concerns (since I share them),
but it's an open question whether or not I've actually achieved that
(especially now I've conceded the point that keeping match patterns
readable is going to require *some* flavour of syntactic shorthand that
will never work in regular assignment targets - while PEP 642 proposes
defining that in terms of a more explicit syntax that *could* be added to
assignment targets, the shorthand forms would still be forever
inconsistent).

Cheers,
Nick.

P.S. FWIW, I'll also note that do have a strong pro-"|" opinion on MatchOr
patterns (I think trying to read "or" in that position would degenerate
into keyword soup, whereas the vertical bar stands out nicely), and have
been burned by enough restrictive JSON parsers that collapse when the
sender adds a new key to an object to be strongly pro "ignore extra mapping
keys by default" in mapping patterns. However, I don't think those kinds of
questions are anywhere near as fundamental as the one about whether or not
potential syntactic consistency with assignment targets should even be a
design goal in the first place.
___
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/X73QQQZNCPBLIAYVJGIJNWEU4Z524XT5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

Hi folks,

I have updated PEP 642 significantly based on the feedback received
over the past week.

Since the Discourse thread hadn't received any comments on it, I
amended the existing thread in place rather than making a new one:
https://discuss.python.org/t/pep-642-constraint-pattern-syntax-for-structural-pattern-matching/5614

The full text of the PEP is quoted in the Discourse thread.

The rendered version of the updated PEP can be found in the usual
place: https://www.python.org/dev/peps/pep-0642/

Relative to the initially published version, the major changes are
based primarily on the counterproposal that Steven D'Aprano posted:

* Explicit equality constraints become "== EXPR" (replacing v1's "?EXPR")
* Explicit identity constraints become "is EXPR" (replacing v1's "?is EXPR")
* Inferred constraints are introduced to deal with the resulting
verbosity problems. These mostly follow the same syntax as PEP 634
proposes for value patterns and literal patterns, but are defined in
terms of the explicit constraints, rather than being the only way to
request the desired semantics.

While I considered ceding the point on using `_` as the wildcard
marker (and had updated the PEP to say that), I couldn't bring myself
to actually do it, especially after reading Thomas Wouters review of
the current state of the pattern matching proposals. So instead this
version proposes the use of `__` in that role, with an explanation of
how that opens a path towards restoring language self-consistency in a
future PEP by making `__` special everywhere, rather than only having
it be special in match patterns.

There are a few other changes that get down into the weeds of actually
implementing these features in the compiler (like introducing a
SkippedBinding node into the AST so most of the compiler doesn't need
to care how the wildcard is spelled in the surface syntax), but I
doubt those are going to matter to most folks in deciding which of the
proposals on offer they prefer (or if they'd prefer continue without
any pattern matching syntax at all).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/IKAMHN3FVNHZEAEIMDRWFIAD4HXFQ24X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Inada Naoki]

Hi, Riccardo.

I'm who removed the __cause__ from tutorial, and I had translated
Japanese translation of official Python document hard.


On Sun, Nov 8, 2020 at 3:07 AM Riccardo Polignieri via Python-Dev
 wrote:
>
> This morning I noticed this new commit, referring to bpo-42179: "Remove 
> mention of __cause__" (https://bugs.python.org/issue42179). From reading this 
> thread, it turns out that a minor confusion in the wording, about __cause__ 
> and __context__, very quickly turned into the decision to completely remove 
> any reference to __cause__, the reason being that "generally speaking (...) 
> we should *reduce* some details from tutorial".
>

Note that the discussion not only in the b.p.o thread, but in this
mailing list too.
Please read this long thread.
https://mail.python.org/archives/list/python-dev@python.org/thread/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/

>
> We all know that the tutorial is "too difficult", not really suitable for 
> beginners (perhaps not even Python beginners!). Having spent a couple of 
> weeks translating it as recently as this spring, I am well aware of this. At 
> times, it feels more like a demo or a features' showcase: a feeling 
> reinforced, by the way, often by the *recent* additions like the special 
> parameters syntax 
> (https://docs.python.org/3/tutorial/controlflow.html#special-parameters).
>

Agree.

> However, unless someone undertakes a sweeping rewriting of the tutorial (and 
> until they do), I think it would be unwise to start cherry-picking the 
> occasional bit of information to expunge or "simplify" from time to time, 
> without an overall guideline.
>

I expect documenting working group will discuss the guideline.

> Reason is, right now the tutorial is packed with informations 
> (beginner-unfriendly as they might be) that you would be hard pressed to find 
> elsewhere in the documentation: see the aforementioned section on special 
> parameters; see the maddening chapter on Classes (and especially the 
> exposition on scopes and namespaces); see, of course, the floating point 
> appendix; and I could go on.
>

Agree. There are tons of beginner unfriendly bits in the tutorial.


> My concern here is that if you start removing or simplifying some 
> "too-difficult-for-a-tutorial" bits of information on an occasional basis, 
> and without too much scrutiny or editorial guidance, you will end up loosing 
> something precious.
>
> Like everyone, I also look forward to an overall rewriting of the tutorial; 
> but in the meantime, I would kindly ask you to be very careful and 
> conservative about deleting information solely for "didactic" reasons.
>

For the record, when I removed the `__cause__` from the tutorial, I
believe I was careful and conservative enough.

I think `from exc` syntax is not new Python users should know.
Documenting implicit chaining is enough for 99% use cases, and `from
None` covers 0.99% of the rest.
So I considered removing explicit chaining (e.g. `from exc`) from the
section too.
But I kept it, because it's a "syntax showcase" even though it will
give more noise to beginners.

And deleting `__cause__` is not solery for "didactic" reason, nor
"loosing something precious."
As written in the b.p.o. issue, mention only `__cause__` "lose some precious".
We need to describe `__context__` and `__suppress_context__` too.
But all of them are documented in library/exceptions.html.
Removing `__cause__` and adding a link to library/exceptions.html
makes sense more than documenting all.

Bests,

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

[Python-Dev] Please do not remove random bits of information from the tutorial

[Riccardo Polignieri via Python-Dev]

Dear all, 

I am the maintainer of an Italian translation of the Python Tutorial: 
https://pytutorial-it.readthedocs.io. 
Since the Italian translation is kept in sync with the original repo (across 
all the branches!), from time to time I get an alert when a change is 
committed. 

This morning I noticed this new commit, referring to bpo-42179: "Remove mention 
of __cause__" (https://bugs.python.org/issue42179). From reading this thread, 
it turns out that a minor confusion in the wording, about __cause__ and 
__context__, very quickly turned into the decision to completely remove any 
reference to __cause__, the reason being that "generally speaking (...) we 
should *reduce* some details from tutorial".


While I have no particular opinion on this specific case, I would strongly urge 
you not to remove random bits of information from the tutorial, even when a 
link to a specific article is handy. 


We all know that the tutorial is "too difficult", not really suitable for 
beginners (perhaps not even Python beginners!). Having spent a couple of weeks 
translating it as recently as this spring, I am well aware of this. At times, 
it feels more like a demo or a features' showcase: a feeling reinforced, by the 
way, often by the *recent* additions like the special parameters syntax 
(https://docs.python.org/3/tutorial/controlflow.html#special-parameters). 

However, unless someone undertakes a sweeping rewriting of the tutorial (and 
until they do), I think it would be unwise to start cherry-picking the 
occasional bit of information to expunge or "simplify" from time to time, 
without an overall guideline. 
Reason is, right now the tutorial is packed with informations 
(beginner-unfriendly as they might be) that you would be hard pressed to find 
elsewhere in the documentation: see the aforementioned section on special 
parameters; see the maddening chapter on Classes (and especially the exposition 
on scopes and namespaces); see, of course, the floating point appendix; and I 
could go on. 

My concern here is that if you start removing or simplifying some 
"too-difficult-for-a-tutorial" bits of information on an occasional basis, and 
without too much scrutiny or editorial guidance, you will end up loosing 
something precious.

Like everyone, I also look forward to an overall rewriting of the tutorial; but 
in the meantime, I would kindly ask you to be very careful and conservative 
about deleting information solely for "didactic" reasons.

thanks a lot
riccardo polignieri
___
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/WNHVZLEO3ZVDOFP2FHRBUQR4GY24RIJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Garrett D'Amore via Python-Dev]

Just one note.  Please don’t confuse illumos and the illumos community with 
Oracle or Solaris.  While the illumos code base owes its origins to Solaris, 
that was due to the acts of Sun and not Oracle and today Oracle refuses to even 
acknowledge the existence of illumos.  illumos is fully open source. 

Sent from my iPhone

> On Oct 30, 2020, at 4:59 PM, Gregory P. Smith  wrote:
> 
> 
> 
>> On Fri, Oct 30, 2020 at 2:30 PM Garrett D'Amore via Python-Dev 
>>  wrote:
>> I’m not on this list.  But I have offered to help - if there are tasks that 
>> need to be done to help this I can help put the weight of a commercial 
>> entity behind it whether that involves assigning our developers to work on 
>> this, helping pay for external developers to do so, or assisting with access 
>> to machine resources. 
>> 
>> For the record there are multiple  illumos distributions and most are both 
>> free and run reasonably well in virtual machines. Claiming that developers 
>> don’t have access as a reason to discontinue the port is a bit disingenuous. 
>> Anyone can get access if they want and if they can figure out how to login 
>> and use Linux then this should be pretty close to trivial for them. 
> 
> Thanks!  It usually isn't just about access.  This email thread and related 
> tweets appear to have served their purpose: To drum up volunteers+resources 
> from the otherwise potentially impacted communities.  The valuable thing is 
> developer time.
> 
> Access: I took it upon myself to spin up some Solaris-derivative VMs for 
> Python dev things in the (now distant) past.  It wasn't a positive 
> experience, I won't do it again.  Bonus on top of that: Oracle, the owner of 
> Solaris, is still actively attempting to destroy the entire software 
> industry.  Working on anything attempting to directly benefit them is a major 
> ethical violation for me.  Others make their own choices.
> 
> I won't even spin up major BSD VMs anymore for a similar reason.  It isn't a 
> good positive use of my time, even despite having an enjoyable past with 
> those OSes and knowing several past and present Free/Net/OpenBSD core devs.
> 
> I look forward to new *Solaris buildbot(s) joining the fleet,
> -gps
___
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/3MA4G4UYFPR2IUVST7REVPY3VSUF7U4X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Stephen J. Turnbull]

Guido van Rossum writes:

 > This I also agree with. We should not assume readers know any
 > particular other language,

Most of my students have Python as their first language, and my
university mandates using it in introductory courses as of this year.

I agree that there are two audiences: those who have some (or a lot)
of experience with programming in other languages, and those who are
programming novices.  I think that the current tutorials are oriented
to the former, and are already getting quite long.  So I don't think
they should be re-oriented to the programming novice.

But as the little girl said, "¿Porque no los dos?" (why not both?)
There are a ton of "Gentle Introduction to Programming using Python"
tutorials out there, I'm sure.  Perhaps we can get one contributed.
(Don't look at me to write one, that would be a mistake.  While I'm
willing and have success as a tutor, my written "tutorials" generally
repel readers due to excess detail and pedantry. :-(  I have no knack
for concise enlightening explanations.)
___
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/RJ626WNLKPVFLTPTMELA52V6D2EOUHZI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Steve Holden]

As I remember the webmaster@ discussions, Mats did go so far as to start a
re-write of the classes section, but it never got as far as a PR.

Kind regards,
Steve


On Fri, Nov 6, 2020 at 5:51 PM Guido van Rossum  wrote:

> Ouch, that's bad. It seems the class tutorial could use an overhaul.
>
> We might also cut a few areas where we go unnecessarily deep (e.g.
> position-only parameters).
>
> On Fri, Nov 6, 2020 at 9:31 AM Mats Wichmann  wrote:
>
>> On 11/6/20 9:07 AM, Marco Sulla wrote:
>> > I started to learn Python with the tutorial, and two things come into
>> my
>> > mind:
>> > 1. The class section seems quite difficult and intimidating for a
>> novel,
>> > while classes in Python are really more simple than in other OO
>> languages
>>
>> Indeed - we got some complaints about the class chapter at the
>> webmas...@python.org alias a while back. The introductory section
>> repeatedly mentions Modula-3 and Smalltalk, languages which more
>> recently minted programmers aren't very likely to be familiar with,
>> which makes it a bit of a daunting beginning - this is the one chapter
>> that could really use a bit of rework, IMO.
>>
>> ___
>> 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/B54VI2DN2AYUXJG4SWSW2BMU5OOCIGSX/
>> 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/QRWFPASA6TKQCDSIOUBYU5OGHPFAUXW3/
> 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/BQ2PWXS4VOTQUU5T3EUCQVKUQC4XQTH7/
Code of Conduct: http://python.org/psf/codeofconduct/