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

[Stephen J. Turnbull]

Ned Batchelder writes:

 > I feel like we are missing a key element of Riccardo's point:
 > "without editorial guidance."   Changes are being made without
 > first having an agreement about what the tutorial should be.

That's really unfortunate.  But there also ought to be an editorial
activity, such as a "tutorial-SIG" within the docs working group (ie,
informality within informality -- IMO the most formal this should get
is a mailing list/discuss channel, and maybe a tracker tag) to have
some visibility into whether changes serve those purposes.

 > Personally, I would rather the tutorial did not try to cover 
 > everything.  If something is only useful to 10% of the readers, I'd 
 > prefer to cover it elsewhere.

I'd raise that 10%, maybe as high as 50%.  Or maybe that's the wrong
dimension to measure, and we should aim for a tutorial that covers
enough for 50% of the readers to write a program that gives them more
utility than just amusement and a feeling of accomplishment.

 > Adding tutorial-style content throughout the rest of the reference
 > documentation seems a fine solution to me.

That's fine if the user knows what to look for, but is it really
discoverable?  In general, I would think that tutorial material should
be most easily discoverable on its own, and that the tutorial should
link to the reference material, and the reference should link, rather
than include, that tutorial.  And should "tutorial" material in a
reference really go beyond short examples of typical use cases?

Maybe these purposes would be be better served by domain-specifici
HOWTOs.  Eg, HOWTO write a mail filter using the mailbox and email
modules.  HOWTO write a web spider using requests and aiohttp.

 > As a compromise, we could include full text for the 80% features in the 
 > tutorial, and in each section, include links to "other topics" or 
 > "advanced features" in other sections.  This would leave the 
 > front-to-back readers of the tutorial with a good 80% overview of the 
 > language, but also let readers find the tangents that are of interest to 
 > them.

I don't know if I agree with this specific outline, but I'm definitely
in agreement with the principle that we should be guided by improving
discoverability.
___
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/4UXUNCC7YE645XG4VEJHPM25IRZXRMFA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

Jim J. Jewett writes:

 > I *hope* this was a typo!  If 
 > 
 > case Point(x=a, y=b):
 > 
 > assigns to a and b (instead of x and y, as in a normal call), then
 > that is ... going to be very easy for me to forget, and to miss
 > even when I'm aware of it.

I don't argue with your main point as a general principle, but I think
I myself would probably be OK with real code where Points are probably
used quite frequently (instead of being introduced in this line ;-)
and the identifiers being bound aren't named "a" and "b".

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

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

[Guido van Rossum]

But Point(x as a) already has a meaning in PEP 634; it’s a positional
argument captured in x *and* in a. (Previously spelled as Point(a := x).
The phrase ‘as a’ can be added after any pattern to *also* capture it in
‘a’. More typically used as e.g.‘Pattern(x, y) as p’, which captures the
first two fields in x and y, and the whole Point in p.

On Sat, Nov 14, 2020 at 23:06 Kyle Stanley  wrote:

> On Sun, Nov 15, 2020 at 1:56 AM Chris Angelico  wrote:
>
>> On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley  wrote:
>> >
>> > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture
>> patterns. This is by far the clearest and easiest to read form I've seen
>> thus far, and I suspect that it would be the easiest to explain to users
>> already familiar with usage of "as" from other areas in Python. A new
>> feature being as distinguishable as possible and easy to explain to
>> existing users is very important in my book, and based on the responses, I
>> think that the current "=" form used in PEP 634 for matching class patterns
>> would be substantially more difficult for users to mentally parse and
>> understand compared to "as".
>> >
>> > It's also worth considering new Python users that might have general OO
>> experience but not with robust pattern matching (e.g. Java-heavy
>> backgrounds). I could definitely see "case Point(x=a, y=b):" being confused
>> for instantiation, whereas usage of "as" makes it more clear that something
>> else is happening (hopefully leading them to search around for more info
>> about Python pattern matching).
>> >
>>
>> case Point(x=as a, y=as b):
>>
>> That doesn't read well to me.
>>
>> Or is there some other spelling of 'as' that makes better sense to you?
>>
>
> The post from Nick that I was primarily replying to used the following
> spelling: "case Point(x as a, y as b):".
> ___
> 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/JBSWERRHKBYAB7OW5HS3E4FGVTXDTJUP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/455PZ4Z5MNQQHN5LUGEJWMD2UXGHDFRY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kyle Stanley]

On Sun, Nov 15, 2020 at 1:56 AM Chris Angelico  wrote:

> On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley  wrote:
> >
> > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture
> patterns. This is by far the clearest and easiest to read form I've seen
> thus far, and I suspect that it would be the easiest to explain to users
> already familiar with usage of "as" from other areas in Python. A new
> feature being as distinguishable as possible and easy to explain to
> existing users is very important in my book, and based on the responses, I
> think that the current "=" form used in PEP 634 for matching class patterns
> would be substantially more difficult for users to mentally parse and
> understand compared to "as".
> >
> > It's also worth considering new Python users that might have general OO
> experience but not with robust pattern matching (e.g. Java-heavy
> backgrounds). I could definitely see "case Point(x=a, y=b):" being confused
> for instantiation, whereas usage of "as" makes it more clear that something
> else is happening (hopefully leading them to search around for more info
> about Python pattern matching).
> >
>
> case Point(x=as a, y=as b):
>
> That doesn't read well to me.
>
> Or is there some other spelling of 'as' that makes better sense to you?
>

The post from Nick that I was primarily replying to used the following
spelling: "case Point(x as a, y as b):".
___
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/JBSWERRHKBYAB7OW5HS3E4FGVTXDTJUP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley  wrote:
>
> FWIW, I'd like to add my +1 to usage of "as" for spelling class capture 
> patterns. This is by far the clearest and easiest to read form I've seen thus 
> far, and I suspect that it would be the easiest to explain to users already 
> familiar with usage of "as" from other areas in Python. A new feature being 
> as distinguishable as possible and easy to explain to existing users is very 
> important in my book, and based on the responses, I think that the current 
> "=" form used in PEP 634 for matching class patterns would be substantially 
> more difficult for users to mentally parse and understand compared to "as".
>
> It's also worth considering new Python users that might have general OO 
> experience but not with robust pattern matching (e.g. Java-heavy 
> backgrounds). I could definitely see "case Point(x=a, y=b):" being confused 
> for instantiation, whereas usage of "as" makes it more clear that something 
> else is happening (hopefully leading them to search around for more info 
> about Python pattern matching).
>

case Point(x=as a, y=as b):

That doesn't read well to me.

Or is there some other spelling of 'as' that makes better sense to you?

ChrisA
(why am I responding to this topic? I'm really not sure.)
___
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/SJ23TYZCYIYCBHFKKKVVEX4MQB726YXM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kyle Stanley]

On Sat, Nov 14, 2020 at 7:54 AM Nick Coghlan  wrote:

> On Sat, 14 Nov 2020 at 09:51, Greg Ewing 
> wrote:
> >
> > On 14/11/20 7:45 am, Brandt Bucher wrote:
> > > with (using your own syntactic flavor):
> > > ```
> > > case >first, *>middle, >last:
> > >  rebuilt = first, *middle, last
> > > case {"key": >value, **>rest}:
> > >  rebuilt = {"key": value, **rest}
> > > case Point(x=>a, y=>b):
> > >  rebuilt = Point(x=a, y=b)
> >
> > I think this is a case where syntax matters. To my eyes this
> > looks far less confusing:
> >
> > case ?first, *?middle, ?last:
> >   rebuilt = first, *middle, last
> > case {"key": ?value, **?rest}:
> >   rebuilt = {"key": value, **rest}
> > case Point(x=?a, y=?b):
> >   rebuilt = Point(x=a, y=b)
>
> Based on the discussion in this thread, v3 of PEP 642 is going to
> propose spelling these as:
>
> case first, *middle, last:
>  rebuilt = first, *middle, last
> case {"key" as value, **rest}:
>  rebuilt = {"key": value, **rest}
> case Point(x as a, y as b):
>  rebuilt = Point(x=a, y=b)
>
> I'm in agreement with the PEP 634 authors that we want to keep
> sequence pattern matching consistent with iterable unpacking as far as
> name binding is concerned. Mapping patterns and class patterns are
> both completely new though, and I think the readability problem there
> is quite similar to the one that existed with walrus patterns in PEP
> 622, and thus amenable to a similar solution (i.e. spell the capture
> patterns for those cases with `as`, not `:` or `=`).
>

FWIW, I'd like to add my +1 to usage of "as" for spelling class capture
patterns. This is by far the clearest and easiest to read form I've seen
thus far, and I suspect that it would be the easiest to explain to users
already familiar with usage of "as" from other areas in Python. A new
feature being as distinguishable as possible and easy to explain to
existing users is very important in my book, and based on the responses, I
think that the current "=" form used in PEP 634 for matching class patterns
would be substantially more difficult for users to mentally parse and
understand compared to "as".

It's also worth considering new Python users that might have general OO
experience but not with robust pattern matching (e.g. Java-heavy
backgrounds). I could definitely see "case Point(x=a, y=b):" being confused
for instantiation, whereas usage of "as" makes it more clear that something
else is happening (hopefully leading them to search around for more info
about Python pattern matching).
___
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/VK6YAMK5NSOZRNRDHLHL7UH67LGVL3HU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Sokolovsky]

Hello,

On Fri, 13 Nov 2020 18:45:55 -
"Brandt Bucher"  wrote:

> Paul Sokolovsky wrote:
> > Use punctuation ("sigils") to mark as-binding terms. This choice
> > still seems to be under-considered. (As in: it doesn't seem like
> > many people, including the PEP authors, tried to say "indeed, what
> > if?" and feel thru it. I mean, try really hard. I trust the "gang
> > of 4" spent maybe whole few hours on that and delivered "no" to all
> > us. It's still not the same as dozens of people trying it over a
> > few months).  
> 
> To anyone actually wondering how much time and mental energy we’ve
> spent on a particular issue: please take a look at our tracker before
> guessing “maybe whole few hours”:

Thanks for the very useful response. (Which follows another useful
from another PEP author, Tobias Kohn,
https://mail.python.org/archives/list/python-dev@python.org/thread/FYGTU4RMZGKTQUANDSTRUSTC5GTZ5WUY/).
Thanks gentlemen for still keeping up the discussion even if you went
thru all those matter many times. 

> - Issue #1(!), April, 29 comments:
> https://github.com/gvanrossum/patma/issues/1
> - Issue #90, June, 84 comments:
> https://github.com/gvanrossum/patma/issues/90
> - Issue #92, June, 33 comments:
> https://github.com/gvanrossum/patma/issues/92
> - Issue #105, June, 17 comments:
> https://github.com/gvanrossum/patma/issues/105
> - Issue #143, August, 7 comments:
> https://github.com/gvanrossum/patma/issues/143
> 
> (I won't judge anyone for skimming a bit; it's a *lot* of discussion.

I have to admit that I didn't read thru it. And fairly speaking, my aim
is not to argue with the PEP authors, but "raise awareness" of the
implications of choices made by PEP634 (and that the choice made there
is not the "absolute winner", but more and more look like a leap of
faith among other viable choices.)  

Anyway, given that you even included the # of messages above, let me
still do some homework and add to stats number of participants in the
ticket thread above (as an indirect way to assess community outreach):

5 + 12 + 8 + 6 + 5

I'm not sure what to do with these numbers (doing max() perhaps?). It's
clear that the discussions there are more active than on the mailing
list.

> Do note, though, that for months I was one of the proponents of store
> sigils like `?` until I was eventually convinced otherwise.)

That's another great answer! Given that PEP622 had 6 authors, it's
pretty mathematically clear that there should have been proponents of
all 3 load/store options, and I wondered who's who.

[]

> I'll also add, for anyone considering choosing yet another ASCII
> symbol off their keyboard and proposing it as a “novel”, “intuitive”
> marker: one problem with most of the hastily suggested adornments are

I don't think the problem is "hastily suggested ". The problem is
more that: despite all your great and multiple considerations, finding
a compromise among you 6, compressing it to a small paragraph of PEP635,
with culminating sentence in it starting with "However, this is based
on the misconception", which sets the tone very well - despite all this
great work, there're still people who think that you didn't do fairness
to the idea of marking the stores.

A possible solution would have been to extend discussion of this option
in PEP635, and start with considering what would be lost by *not*
adopting that approach, instead of coloring it all in a dismissive tone
from the start.

I know that might have been hard. As we know, an "alternative" PEP 642
was spawned exactly out of rejection of additional information
regarding "sigils for loads" idea:
https://github.com/python/peps/pull/1564

> that they do not nest very well, for even simple cases. 

I propose to add a unary prefix operator (choices among ">", ">>",
"->", "@", etc.) Those do nest well. Some are completely unambiguous.

> Further, the
> fact that constructions like `p = Point(x, y)` look exactly the same
> as deconstructions like `case Point(x, y):` is absolutely intentional
> (which touches back on Guido’s “rhyme” comment last night).

I don't think that "exactly the same" is the right words, or
expectations to have. For example, PEP622 used phrase "It would break
the syntactic parallels of the current grammar".

And that's the whole point: `case Point(>x, >y)` is exactly parallel
to `p = Point(x, y)`! The only difference is that the bind-to terms
(here, the variables) are explicitly marked.

Consider if the language had a color as syntactic means. Then in `p =
Point(x, y)`, x and y would be colored in one way, but in `case
Point(x, y)` - in different way. But they would be exactly parallel, and
maybe even "the same". Thankfully, we don't use colors as syntactic
means. The closest device we have is punctuation, and that's where
idea to use sigils come from.

> 
> Very briefly, compare the current syntax:
> 
> ```
> case first, *middle, last:
> rebuilt = first, *middle, last
> case {"key": value, **rest}:
> rebuilt = {"key": value, **res

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Christian Nielsen]

I very much second this opinion

/Christian


On Sat, 14 Nov 2020, 15.16 Joao S. O. Bueno,  wrote:

>
>
> On Sat, 14 Nov 2020 at 10:16, Nick Coghlan  wrote:
>
>> On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
>> >
>> > I have read a great deal of discussion on the pattern matching PEPs and
>> less formal discussions.  It is possible I have overlooked some post in all
>> of that, of course.
>> >
>> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose
>> applies to this too :-).
>> >
>> > One idea that I cannot recall seeing, but that seems to make sense to
>> me and fit with Python's feel is using a WORD to distinguish between a
>> variable value and a binding target.  That is, instead of a special symbol
>> prefixing or suffixing a name, either to indicate it is or is not a binding
>> target.  Of course, whether the extra word would be used for binding or for
>> NOT binding is a question still.
>>
>> If someone was prepared to pursue this to the level of writing a 3rd
>> competing PEP, the variant I would personally like to see written up
>> is the one where capture patterns are all prefixed with the keyword
>> `as`.
>>
>> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
>> match patterns with a capture pattern, and I'm going to be amending
>> PEP 642 to propose using `as` when embedding capture patterns inside
>> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
>> From there, it's an entirely plausible step to also require the `as`
>> prefix on capture patterns in sequence patterns and as top level
>> standalone patterns.
>>
>> I personally don't think that extra step would be a good idea due to
>> the inconsistency with name binding and iterable unpacking in regular
>> assignment statements (if I liked the idea, I'd have already included
>> it in PEP 642), but I think "anchor match patterns in normal
>> expressions rather than assignment target syntax" is a credible enough
>> idea that the overall design process would benefit from having a
>> champion write it up.
>>
>> > To me these read better than the punctuation characters.  But I guess
>> some folks have suggested enlisting 'as', which is a word, of course.
>>
>> Indeed, and one that doesn't look too bad for top level patterns:
>>
>> NOT_FOUND = 404
>> match http_code:
>>   case 200:
>>   print("OK document")
>>   case NOT_FOUND:  # use the variable value
>>   print("Document not found")
>>   case as other_code:  # bind this name
>>   print("Other HTTP code")
>>
>> It starts to look a bit more strange when matching sequences, though:
>>
>> match seq:
>> case as first, *middle, as last:
>> ... # Or should that be "*as middle"?
>>
>
> Although the spacing there should probably remain optional, I think
> that "* as middle" is very straightforward and easy to read.
>
>
>>
>> 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/LKRWAQX57OJANWQHG2SWL2UG4ZZRRKPF/
>> 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/GFVLLQVHN2QWNX6LWHESBGRMXHLF3Z74/
> 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/7NFU33AMGMPJDZDODMPN5VUL64RUDUW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Joao S. O. Bueno]

On Sat, 14 Nov 2020 at 10:16, Nick Coghlan  wrote:

> On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
> >
> > I have read a great deal of discussion on the pattern matching PEPs and
> less formal discussions.  It is possible I have overlooked some post in all
> of that, of course.
> >
> > ... OK, just saw Guido's "wait for new SC" comment, which I suppose
> applies to this too :-).
> >
> > One idea that I cannot recall seeing, but that seems to make sense to me
> and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target.  That is, instead of a special symbol
> prefixing or suffixing a name, either to indicate it is or is not a binding
> target.  Of course, whether the extra word would be used for binding or for
> NOT binding is a question still.
>
> If someone was prepared to pursue this to the level of writing a 3rd
> competing PEP, the variant I would personally like to see written up
> is the one where capture patterns are all prefixed with the keyword
> `as`.
>
> PEP 634 already uses the `PATTERN as NAME` syntax to combine other
> match patterns with a capture pattern, and I'm going to be amending
> PEP 642 to propose using `as` when embedding capture patterns inside
> class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
> From there, it's an entirely plausible step to also require the `as`
> prefix on capture patterns in sequence patterns and as top level
> standalone patterns.
>
> I personally don't think that extra step would be a good idea due to
> the inconsistency with name binding and iterable unpacking in regular
> assignment statements (if I liked the idea, I'd have already included
> it in PEP 642), but I think "anchor match patterns in normal
> expressions rather than assignment target syntax" is a credible enough
> idea that the overall design process would benefit from having a
> champion write it up.
>
> > To me these read better than the punctuation characters.  But I guess
> some folks have suggested enlisting 'as', which is a word, of course.
>
> Indeed, and one that doesn't look too bad for top level patterns:
>
> NOT_FOUND = 404
> match http_code:
>   case 200:
>   print("OK document")
>   case NOT_FOUND:  # use the variable value
>   print("Document not found")
>   case as other_code:  # bind this name
>   print("Other HTTP code")
>
> It starts to look a bit more strange when matching sequences, though:
>
> match seq:
> case as first, *middle, as last:
> ... # Or should that be "*as middle"?
>

Although the spacing there should probably remain optional, I think
that "* as middle" is very straightforward and easy to read.


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

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

[Ned Batchelder]

On 11/9/20 2:25 PM, Raymond Hettinger wrote:



On Nov 7, 2020, at 9:51 AM, Riccardo Polignieri via Python-Dev 
 wrote:

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.

I concur with you sentiments and do not want the tutorial to be dumbed down.


I feel like we are missing a key element of Riccardo's point: "without 
editorial guidance."   Changes are being made without first having an 
agreement about what the tutorial should be.


Personally, I would rather the tutorial did not try to cover 
everything.  If something is only useful to 10% of the readers, I'd 
prefer to cover it elsewhere.  Adding tutorial-style content throughout 
the rest of the reference documentation seems a fine solution to me.  As 
an example, I tried to use ContextVars for the first time the other day, 
and would have welcomed a description on their page about how they might 
be used, where they are useful, and so on.




Here are a few thoughts on the subject:

* The word "tutorial" does not imply "easy".  Instead it is a self-paced, example driven 
walk-through of the language.  That said, if the word "tutorial" doesn't sit well, then just rename 
the guide.

* The world is full of well-written guides for beginners.  The variety is especially important because "beginner" means many different 
things:  "never programmed before", "casually checking out what the language offers", "expert in some other language", 
"is a student in elementary school", "is a student in high school", "is an electrical engineer needing write scripts",  
etc.

* One thing that makes the current tutorial special is that much of it was 
written by Guido.  Delete this text and you lose one of the few places where 
his voice comes through.

* There is value in having non-trivial coverage of the language.  When people 
ask how __cause__ works, we can link to the tutorial.  Otherwise, we have to 
throw them to the wolves by linking to the unfriendly, highly technical 
reference guide or to a PEP.
Linking to content is a great use-case.  There's no need for __cause__ 
to be covered in a linear front-to-back tutorial just so we can link to 
it.  When someone asks how __cause__ works, we could link to the (not 
yet written) walkthrough about __cause__ elsewhere.


* For many people, our tutorial serves as the only systematic walk-through of 
the language.  If you decide to drop the mention of complex numbers, the odds 
of a person ever finding about that capability drop to almost zero.


As a compromise, we could include full text for the 80% features in the 
tutorial, and in each section, include links to "other topics" or 
"advanced features" in other sections.  This would leave the 
front-to-back readers of the tutorial with a good 80% overview of the 
language, but also let readers find the tangents that are of interest to 
them.


This is the sort of overall design of the tutorial we should be undertaking.



* My suggestion is that we add a section to the beginning of the tutorial with external 
links elsewhere, "If you are ten years old, go here.  If have never programmed 
before, go here, etc"

* If you think the word tutorial implies fluffy and easy, then let's just rename it to 
"Language walk-through with examples" or some such.

* FWIW, I've closely monitored the bug tracker daily for almost two decades.  
We almost never get a user complaint that the tutorial is too advanced.  For 
the most part, it has long been of good service to users.  Almost certainly it 
can be improved, but hopefully not be dropping content.


Bug reports on bpo are a really bad way to gauge how the tutorial is 
working for people.  Most people looking for a "tutorial" are not going 
to think to write bug reports like you are expecting, much less find 
bpo, or go to the trouble of creating an account to write one.


--Ned.





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

[Python-Dev] Re: Configure Python initialization (PyConfig) in Python

[Nick Coghlan]

On Wed, 11 Nov 2020 at 09:59, Victor Stinner  wrote:
>
> Hi,
>
> If you embed Python in Python, I would like your opinion on
> https://bugs.python.org/issue42260 issue which adds a way to configure
> the Python initialization in Python.
>
> I'm looking for feedback from people who embed Python and have issues
> to configure Python as they wish.
>
> Simple example (just to show how the API would look like) setting the
> the bytes_warning option:
> 
> import _testinternalcapi
> import sys
>
> assert sys.flags.bytes_warning == 0
>
> config = _testinternalcapi.get_config()  # Copy PyConfig
> config['bytes_warning'] = 1  # regular Python dict
> _testinternalcapi.set_config(config)  # Update PyConfig and sys
>
> assert sys.flags.bytes_warning == 1
> 
>
> The example already works in the current master branch!

Nice!

I remember the work you put in getting runtime reconfiguration working
again for 3.7.1, so it's cool to see that capability maturing even
further.

> Nick Coghlan recently withdrew his PEP 432 since PEP 587 was rejected.

s/rejected/accepted/ :)

> It made me sad :-(

Seeing the huge improvements that have been made to the startup
management code since I first wrote PEP 432 makes me happy.

Sure, the technical details aren't exactly what I first envisioned,
but I never expected those to survive exactly as written - the problem
is simply too big and too complex for my first guess at a plausible
way of fixing it to be exactly what we ended up doing :)

> * [WIP] Rewrite Modules/getpath.c (1600 lines of C code) to
> Lib/_getpath.py (700 lines of Python code)
>
> See https://bugs.python.org/issue42260 for the work-in-progress.

Wow, it's one thing to suggest this as a desirable goal, and another
to see it so close to actually happening! Very cool :)

> From a practical point of view, executing Python code to initialize
> Python requires freezing this code as a frozen module (as I did for
> _getpath.py in my PR). I don't know if it's easy to do that in an
> application embedding Python right now.

It's still not trivial, but it's easier now that we do it in the
standard library (since it means there is reference code to copy).

> My remaining problem is that my PR changes PyConfig_Read(): it no
> longer computes the Python Path Configuration, since it is now
> implemented in Python. IMO it's an acceptable drawback compared to the
> benefit of these new features.

Even though I wouldn't expect it to be controversial, it's probably
worth writing up this migration of the path configuration code from C
to Python as a PEP, along the lines of what we suggested in the last
part of the PEP 432 withdrawal notice.

The change has the potential to produce unexpected consequences for
folks inadvertently relying on the quirks of the current
implementation, and having the PEP there to cover the technical
details means we can provide more information than could be squeezed
into a single paragraph in the What's New document.

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

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

[Ned Batchelder]

I think when Riccardo said "The PEPs are the worst," he meant that PEPs 
do not work well as documentation for features, because it was not their 
purpose.  PEPs are designed to be proposals, and then summaries of 
decisions.  I agree with him that linking to PEPs should be for 
supporting information about the rationale of a feature; they should 
only be used as the documentation of a feature as a last resort.


--Ned.

On 11/12/20 3:45 PM, Guido van Rossum wrote:
The correct place for the docs for __cause__ and __context__ is in the 
section in the library reference about exceptions. There's quite a bit 
about them there already. That's where the tutorial should link as well.


And now I ask you to stop complaining (your "the PEPs are the worst" 
does not help your cause).


On Thu, Nov 12, 2020 at 12:30 PM Riccardo Polignieri via Python-Dev 
mailto:python-dev@python.org>> wrote:


> There is value in having non-trivial coverage of the language. 
When people ask how
> __cause__ works, we can link to the tutorial.

I don't necessarily agree with the rest, but I think this is very
important - at least, in the
current situation. Maybe in the future we will be able to
rearrange and move some parts
of the tutorial into the "how to" section, and/or to write more
introductions to the various
sections of the documentation... but for now, the tutorial is all
we have.

> Otherwise, we have to throw them to the
> wolves by linking to the unfriendly, highly technical reference
guide or to a PEP.

Indeed. The PEPs are the worst, more often than not. I remember
when I first learned Pyhton,
every time the documentation linked to a PEP, I felt a shiver down
my spine.

r.
___
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/LHGZNTRKU2Z2OD3W7DPFEDS274OBFE7F/


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

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Nick Coghlan]

On Fri, 13 Nov 2020 at 09:39, David Mertz  wrote:
>
> I have read a great deal of discussion on the pattern matching PEPs and less 
> formal discussions.  It is possible I have overlooked some post in all of 
> that, of course.
>
> ... OK, just saw Guido's "wait for new SC" comment, which I suppose applies 
> to this too :-).
>
> One idea that I cannot recall seeing, but that seems to make sense to me and 
> fit with Python's feel is using a WORD to distinguish between a variable 
> value and a binding target.  That is, instead of a special symbol prefixing 
> or suffixing a name, either to indicate it is or is not a binding target.  Of 
> course, whether the extra word would be used for binding or for NOT binding 
> is a question still.

If someone was prepared to pursue this to the level of writing a 3rd
competing PEP, the variant I would personally like to see written up
is the one where capture patterns are all prefixed with the keyword
`as`.

PEP 634 already uses the `PATTERN as NAME` syntax to combine other
match patterns with a capture pattern, and I'm going to be amending
PEP 642 to propose using `as` when embedding capture patterns inside
class patterns (`ATTR as NAME`) and mapping patterns (`KEY as NAME`).
>From there, it's an entirely plausible step to also require the `as`
prefix on capture patterns in sequence patterns and as top level
standalone patterns.

I personally don't think that extra step would be a good idea due to
the inconsistency with name binding and iterable unpacking in regular
assignment statements (if I liked the idea, I'd have already included
it in PEP 642), but I think "anchor match patterns in normal
expressions rather than assignment target syntax" is a credible enough
idea that the overall design process would benefit from having a
champion write it up.

> To me these read better than the punctuation characters.  But I guess some 
> folks have suggested enlisting 'as', which is a word, of course.

Indeed, and one that doesn't look too bad for top level patterns:

NOT_FOUND = 404
match http_code:
  case 200:
  print("OK document")
  case NOT_FOUND:  # use the variable value
  print("Document not found")
  case as other_code:  # bind this name
  print("Other HTTP code")

It starts to look a bit more strange when matching sequences, though:

match seq:
case as first, *middle, as last:
... # Or should that be "*as middle"?

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

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

[Nick Coghlan]

On Sat, 14 Nov 2020 at 09:51, Greg Ewing  wrote:
>
> On 14/11/20 7:45 am, Brandt Bucher wrote:
> > with (using your own syntactic flavor):
> > ```
> > case >first, *>middle, >last:
> >  rebuilt = first, *middle, last
> > case {"key": >value, **>rest}:
> >  rebuilt = {"key": value, **rest}
> > case Point(x=>a, y=>b):
> >  rebuilt = Point(x=a, y=b)
>
> I think this is a case where syntax matters. To my eyes this
> looks far less confusing:
>
> case ?first, *?middle, ?last:
>   rebuilt = first, *middle, last
> case {"key": ?value, **?rest}:
>   rebuilt = {"key": value, **rest}
> case Point(x=?a, y=?b):
>   rebuilt = Point(x=a, y=b)

Based on the discussion in this thread, v3 of PEP 642 is going to
propose spelling these as:

case first, *middle, last:
 rebuilt = first, *middle, last
case {"key" as value, **rest}:
 rebuilt = {"key": value, **rest}
case Point(x as a, y as b):
 rebuilt = Point(x=a, y=b)

I'm in agreement with the PEP 634 authors that we want to keep
sequence pattern matching consistent with iterable unpacking as far as
name binding is concerned. Mapping patterns and class patterns are
both completely new though, and I think the readability problem there
is quite similar to the one that existed with walrus patterns in PEP
622, and thus amenable to a similar solution (i.e. spell the capture
patterns for those cases with `as`, not `:` or `=`).

Cheers,
Nick.

P.S. I've started my TODO list for v3 at
https://github.com/ncoghlan/peps/issues/6

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

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

[Nick Coghlan]

On Sat, 14 Nov 2020 at 07:55, Joao S. O. Bueno  wrote:
> On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett  wrote:
>>
>> I *hope* this was a typo!  If
>>
>> case Point(x=a, y=b):
>>
>> assigns to a and b (instead of x and y, as in a normal call), then that is 
>> ... going to be very easy for me to forget, and to miss even when I'm aware 
>> of it.
>
>
> No typo -  this is _precisely_what the main proposal on PEPs 634, 635 and 636 
> is suggesting, and tha PEP 642 is trying to avoid.

PEP 642 isn't trying to avoid it yet, as it wasn't something that had
previously occurred to me as a possible problem (assigning to a
"function call" is already illegal syntax, so PEP 642 currently
inherits the spelling of class patterns unchanged from PEP 634, and
the same is also mostly true for mapping patterns).

Now that the point has been raised, though, my idea for addressing it
would be somewhat similar to the fix applied for walrus patterns
between PEP 622 and PEP 634:

* To capture a mapping key or instance attribute, don't use ":" or "=", use "as"
* You would only use ":" or "=" if you wanted to specify a subpattern
to match the value against
* Specifying an irrefutable pattern other than the wildcard pattern on
a mapping key or instance attribute would be a syntax error

That approach would give the following:

case Point(x as a, y as b):
... # A Point object with x & y attributes, capturing those to
"a" and "b"
case object(x=__, y=__):
... # Any object with x & y attributes, not capturing anything
case object(x=a, y=b):
... # Syntax Error (matching instance attribute against a
non-wildcard irrefutable pattern)


case {"x" as a, "y" as b):
... # A mapping with "x" & "y" keys, capturing those to "a" and "b"
case {"x":__, "y":__}:
... # A mapping with "x" & "y" keys, not capturing anything
case {"x":a, "y":b}:
... # Syntax Error (matching mapping value against a
non-wildcard irrefutable pattern)

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

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

[Nick Coghlan]

On Sat, 14 Nov 2020 at 01:59, Baptiste Carvello
 wrote:
>
> Hi,
>
> Le 12/11/2020 à 18:55, Guido van Rossum a écrit :
> > The position of PEP 622/634/535/636 authors is clear:
>
> well, let me first emphasize that I did *not* mean to reopen the
> discussion on those PEPs, which explain and discuss their design choices
> thoroughly (even better since the rewrite, thanks for that). And I
> definitely did not mean to spawn another "mark capture or value"
> subthread… I thought "PEP 642 v2" in the thread title was explicit
> enough, should have been more cautious :-)
>
> PEP 642 states as a design principle that parallelism between patterns
> and assignments should be kept as much as possible (let's not discuss
> this principle here). Thus, introducing different semantics for dotted
> names deserves a discussion in that PEP (by contrast, literal
> constraints need little discussion, because they have no semantics in
> assignments).

You're right, I had missed that I didn't mention attribute syntax
specifically in
https://www.python.org/dev/peps/pep-0642/#keeping-inferred-equality-constraints

The rationale is the same as it is in PEP 635: comparing against enum
values is likely to be super common, and requiring the extra "=="
sigils in that case at least arguably hinders readability rather than
helping it.

I actually find most of the predictions of likely usage patterns in
PEP 635 entirely plausible - where I differ with the authors of that
PEP is in whether or not we need to offer explicit override syntax for
the cases where those predictions turn out to be wrong, rather than in
our opinions of what the most common use cases are actually going to
be.

> > we see this as a
> > necessary feature to support using enums (e.g. Color.RED) or constants
> > defined in other modules (e.g. re.I) when simple switch functionality is
> > being migrated from literals (e.g. case 404) to named constants (e.g.
> > case HTTPStatus.NOT_FOUND). Bothering users with the technicality of
> > needing to use '==' here is a big usability hit.
>
> Indeed, enums and other dotted constants are the heart of the matter.
> And I get your point about not making useful refactoring more difficult.
> Still it could make sense (in the philosophy of PEP 642, again) to defer
> the choice and see how strong the need is. What PEP 642 ends up
> proposing will be Nick Coghlan's call.

I opted to include the inferred equality constraints for attributes
specifically to make the revised PEP 642 almost purely additive over
PEP 634 - while v1 removed a lot of things (which raised several
legitimate readability and usability concerns), the only things v2
outright removes are the inferred constraints for True and False (on
grounds of ambiguity).

The rest of the changes are now either new additions (explicit
identity and equality constraints), changes in spelling
(double-underscore vs single-underscore for wildcards), or slight
changes in how constructs are defined (the inferred constraints for
literals and attribute lookups get redefined as syntactic sugar for
their explicit counterparts, rather than being first class constructs
in their own right).

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

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Paul Sokolovsky]

Hello,

On Thu, 12 Nov 2020 19:38:38 -0400
David Mertz  wrote:

[]
> One idea that I cannot recall seeing, but that seems to make sense to
> me and fit with Python's feel is using a WORD to distinguish between a
> variable value and a binding target.  That is, instead of a special

> case value NOT_FOUND:  # use the variable value
> print("Document not found")

> case bind OTHER_CODE:  # bind this name
> print("Other HTTP code")

> To me these read better than the punctuation characters.  But I guess
> some folks have suggested enlisting 'as', which is a word, of course.

This is too verbose, COBOL-style. The whole push is to find concise,
yet intuitive and visible "sigils" for one possibility vs another, then
see how all 3 options (3rd being what's encoded in PEP634, sigil-less,
but with adhoc syntactic constraints) look and feel.

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/6JZSRTETXPXFXGVYVTRT4SCQXHVP4DHG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On Fri., 13 Nov. 2020, 4:01 am Guido van Rossum,  wrote:

> The position of PEP 622/634/535/636 authors is clear: we see this as a
> necessary feature to support using enums (e.g. Color.RED) or constants
> defined in other modules (e.g. re.I) when simple switch functionality is
> being migrated from literals (e.g. case 404) to named constants (e.g. case
> HTTPStatus.NOT_FOUND). Bothering users with the technicality of needing to
> use '==' here is a big usability hit.
>

Right, this was a part of Steven D'Aprano's counterproposal that I found
compelling, so PEP 642 now keeps the inferred equality constraints for the
patterns that are unambiguous in context.

The "==" is only required when the expression would otherwise be
interpreted as a capture pattern, or wouldn't be allowed in a pattern at
all.

Cheers,
Nick.


> On Thu, Nov 12, 2020 at 7:38 AM Baptiste Carvello <
> devel2...@baptiste-carvello.net> wrote:
>
>> Hi,
>>
>> Le 08/11/2020 à 07:47, Nick Coghlan a écrit :
>> > Hi folks,
>> >
>> > I have updated PEP 642 significantly based on the feedback received
>> > over the past week.
>> >
>> > [...]
>> a change that I feel is insufficiently discussed is the choice to have
>> "attr_constraint" as an inferred constraint. I can think of arguments to
>> defer it for now at least:
>>
>> * it is a one way door (if dotted names are made a constraint pattern
>> now, they can't become a capture pattern later);
>>
>> * it makes a difference from assignment target syntax, where you can
>> assign to a dotted name;
>>
>> * the shorthand notation is less valuable than for literals, as dotted
>> names are verbose already, 3 more characters make little difference;
>>
>> * the user has no explicit syntax to override the inferred semantics.
>>
>> I feel like some discussion of this choice in the PEP would make sense.
>>
>> Cheers,
>> Baptiste
>> ___
>> 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/RQPUV7PABLBNYJ7FI7QYCS6TKJ4H2Q2A/
>> 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/DPDHLPKAG3ATDH47NZNWGPK2FKBCY7WR/
> 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/4MY4YSRZZIYBUTETYPF3EAPGVWC26YYF/
Code of Conduct: http://python.org/psf/codeofconduct/