[Python-Dev] Re: Speeding up CPython

[Ronald Oussoren via Python-Dev]

> On 20 Oct 2020, at 14:53, Mark Shannon  wrote:
> 
> Hi everyone,
> 
> CPython is slow. We all know that, yet little is done to fix it.
> 
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few 
> years. But it needs funding.
> 
> I am aware that there have been several promised speed ups in the past that 
> have failed. You might wonder why this is different.
> 
> Here are three reasons:
> 1. I already have working code for the first stage.
> 2. I'm not promising a silver bullet. I recognize that this is a substantial 
> amount of work and needs funding.
> 3. I have extensive experience in VM implementation, not to mention a PhD in 
> the subject.
> 
> My ideas for possible funding, as well as the actual plan of development, can 
> be found here:
> 
> https://github.com/markshannon/faster-cpython
> 
> I'd love to hear your thoughts on this.

I don’t have anything useful to add to the discussion, other than to say that 
I’m happing to see that
someone is willing to spent a significant amount of effort on making CPython 
faster.  Especially
when that someone has worked on faster Python implementation before (look for a 
HotPy talk at EuroPython).

I’m not too worried about the technical part and have no expertise at funding 
at all. I am worried that
merging this work will take a significant amount of effort. This is likely to 
result in fairly significant changes
to the core interpreter, and it might be hard to find enough core devs that 
willing and able to review
changes in a timely manner.

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

[Python-Dev] Re: Speeding up CPython

[Mark Shannon]

Hi Greg,

On 21/10/2020 11:57 pm, Greg Ewing wrote:

A concern I have about this is what effect it will have on the
complexity of CPython's implementation.

CPython is currently very simple and straightforward. Some parts
are not quite as simple as they used to be, but on the whole it's
fairly easy to understand, and I consider this to be one of its
strengths.


I'm not sure that it is "very simple and straightforward".



I worry that adding four layers of clever speedup tricks will
completely destroy this simplicity, leaving us with something
that can no longer be maintained or contributed to by
ordinary mortals.



The plan is that everything will be accessible to someone with a CS 
degree. Any code base takes time and work to get familiar with it.
There is no reason why this code should be any easier or harder to 
understand than any other domain-specific code.


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

[Python-Dev] Re: Speeding up CPython

[Mark Shannon]

Hi Nathaniel,

On 22/10/2020 7:36 am, Nathaniel Smith wrote:

Hi Mark,

This sounds really cool. Can you give us more details? Some questions 
that occurred to me while reading:


- You're suggesting that the contractor would only be paid if the 
desired 50% speedup is achieved, so I guess we'd need some objective 
Python benchmark that boils down to a single speedup number. Did you 
have something in mind for this?


- How much of the work has already been completed?


A fair bit of stage 1, and much research and design for the later stages.



- Do you have any preliminary results of applying that work to that 
benchmark? Even if it's preliminary, it would still help a lot in making 
the case for this being a realistic plan.


Getting a PGO/LTO comparison against 3.10 is tricky.
Mainly because I'm relying on merging a bunch of patches and expecting 
it to work :)


However, on a few simple benchmarks I'm seeing about a 70% speedup vs 
master for both default and LTO configures.


I would expect a lower speedup on a wider range of benchmarks with a 
PGO/LTO build. But 50% is definitely achievable.


Cheers,
Mark.



-n

On Tue, Oct 20, 2020 at 6:00 AM Mark Shannon > wrote:


Hi everyone,

CPython is slow. We all know that, yet little is done to fix it.

I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.

I am aware that there have been several promised speed ups in the past
that have failed. You might wonder why this is different.

Here are three reasons:
1. I already have working code for the first stage.
2. I'm not promising a silver bullet. I recognize that this is a
substantial amount of work and needs funding.
3. I have extensive experience in VM implementation, not to mention a
PhD in the subject.

My ideas for possible funding, as well as the actual plan of
development, can be found here:

https://github.com/markshannon/faster-cpython

I'd love to hear your thoughts on this.

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



--
Nathaniel J. Smith -- https://vorpus.org 

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

[Python-Dev] Re: Speeding up CPython

[Paul Moore]

On Thu, 22 Oct 2020 at 12:52, Mark Shannon  wrote:
> Getting a PGO/LTO comparison against 3.10 is tricky.
> Mainly because I'm relying on merging a bunch of patches and expecting
> it to work :)
>
> However, on a few simple benchmarks I'm seeing about a 70% speedup vs
> master for both default and LTO configures.
>
> I would expect a lower speedup on a wider range of benchmarks with a
> PGO/LTO build. But 50% is definitely achievable.

Apologies if this is already mentioned somewhere, but is this across
all supported platforms (I'm specifically interested in Windows) or is
it limited to only some? I assume the long-term expectation would be
to get the speedup on all supported platforms, I'm mainly curious as
to whether your current results are platform-specific or general.

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

[Python-Dev] Re: Speeding up CPython

[Mark Shannon]

Hi Paul,

On 22/10/2020 1:18 pm, Paul Moore wrote:

On Thu, 22 Oct 2020 at 12:52, Mark Shannon  wrote:

Getting a PGO/LTO comparison against 3.10 is tricky.
Mainly because I'm relying on merging a bunch of patches and expecting
it to work :)

However, on a few simple benchmarks I'm seeing about a 70% speedup vs
master for both default and LTO configures.

I would expect a lower speedup on a wider range of benchmarks with a
PGO/LTO build. But 50% is definitely achievable.


Apologies if this is already mentioned somewhere, but is this across
all supported platforms (I'm specifically interested in Windows) or is
it limited to only some? I assume the long-term expectation would be
to get the speedup on all supported platforms, I'm mainly curious as
to whether your current results are platform-specific or general.


There is nothing platform specific.
I've only tested on Linux. I hope that the speedup on Windows should be 
a bit more, as MSVC seems to do better jump fusion than GCC.

(Not tested clang).

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

[Python-Dev] Re: Speeding up CPython

[Marco Sulla]

On Thu, 22 Oct 2020 at 14:25, Mark Shannon  wrote:

> MSVC seems to do better jump fusion than GCC.
>

Maybe I'm wrong, since I only take a look at dict, tuple and set C code,
but it does not seems to me that there's more than 1-2 GOTOs in every
CPython function, and they can't be merged.
___
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/KFUG4QXOS25AEYIAWX4FBGO6LQMA6OMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Steve Dower]

On 22Oct2020 1341, Marco Sulla wrote:
On Thu, 22 Oct 2020 at 14:25, Mark Shannon > wrote:


MSVC seems to do better jump fusion than GCC.


Maybe I'm wrong, since I only take a look at dict, tuple and set C code, 
but it does not seems to me that there's more than 1-2 GOTOs in every 
CPython function, and they can't be merged.


There are vastly more jumps generated than what you see in the source 
code. You'll need to compare assembly language to get a proper read on this.


But I don't think that's necessary, since processors do other kinds of 
clever things with jumps anyway, that can variously improve/degrade 
performance from what the compilers generate.


Benchmarks on consistent hardware are what matter, not speculation about 
generated code.


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

[Python-Dev] Re: PyPy performance stats (was Re: Speeding up CPython)

[Lele Gaifax]

Antoine Pitrou  writes:

> On Wed, 21 Oct 2020 22:48:59 +1100
> Chris Angelico  wrote:
>>
>> SQLAlchemy seems to be slower, but if you're using SQLAlchemy, you're
>> probably more concerned about database performance than the CPU cost
>> inside Python.
>
> I certainly wouldn't say that.  The ORM's overhead can be quite
> important, and SQLAlchemy has dedicated C extensions to mitigate it.

To be precise, that's unrelated to the ORM layer: the C extension speed ups
the handling of the "records" returned by a database driver, so basically a
custom mixin between a tuple and a dictionary.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.
___
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/ZWLEY4BJYL4A3ZBBKUIAFXXL62RPFRVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Barry Warsaw]

I don’t have much to add to this thread, except to ask whether Mark has been in 
contact with Carl Shapiro.  Carl’s posted here before, but I don’t think he’s 
an active mailing list participant.  Carl has a lot of experience with VMs and 
has been doing interesting work on performant Python implementations at 
Facebook.  You might want to reach out to him.

Cheers,
-Barry



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

[Python-Dev] Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

[Guido van Rossum]

After the pattern matching discussion died out, we discussed it with the
Steering Council. Our discussion ended fairly positive, but there were a
lot of problems with the text. We decided to abandon the old PEP 622 and
break it up into three parts:

- PEP 634: Specification
- PEP 635: Motivation and Rationale
- PEP 636: Tutorial

This turned out to be more work than I had expected (basically we wrote all
new material) but we've finally made it to a point where we can request
feedback and submit the new version to the SC for approval.

While the text of the proposal is completely different, there aren't that
many substantial changes:

- We changed walrus patterns ('v := p') to AS patterns ('p as v').
- We changed the method of comparison for literals None, False, True to use
'is' instead of '=='.
- SyntaxError if an irrefutable case[1] is followed by another case block.
- SyntaxError if an irrefutable pattern[1] occurs on the left of '|', e.g.
'x | [x]'.
- We dropped the `@sealed` decorator and everything aimed at static type
checkers.

[1] An irrefutable pattern is one that never fails, notably a wildcard or a
capture. An irrefutable case has an irrefutable pattern at the top and no
guard. Irrefutability is defined recursively, since an '|' with an
irrefutable pattern on either side is itself irrefutable, and so is an AS
pattern with an irrefutable pattern before 'as'.

The following issues were specifically discussed with the SC:

- Concerns about side effects and undefined behavior. There's now some
specific language about this in a few places (giving the compiler freedom
to optimize), and a section "Side Effects and Undefined Behavior".

- Footgun if `case NAME:` is followed by another case. This is now a
SyntaxError.

- Adding an 'else' clause. We decided not to add this; motivation in PEP
635.

- Alternative 'OR' symbol. Not changed; see PEP 635.

- Alternative wildcard symbol. Not changed, but Thomas wrote PEP 640 which
proposes '?' as a general assignment target. PEP 635 has some language
against that idea.

- Alternative indentation schemes. We decided to stick with the original
proposal; see PEP 635.

- Marking all capture variables with a sigil. We all agreed this was a bad
idea; see PEP 635.

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

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

[MRAB]

On 2020-10-22 17:48, Guido van Rossum wrote:
After the pattern matching discussion died out, we discussed it with the 
Steering Council. Our discussion ended fairly positive, but there were a 
lot of problems with the text. We decided to abandon the old PEP 622 and 
break it up into three parts:


- PEP 634: Specification
- PEP 635: Motivation and Rationale
- PEP 636: Tutorial

This turned out to be more work than I had expected (basically we wrote 
all new material) but we've finally made it to a point where we can 
request feedback and submit the new version to the SC for approval.


While the text of the proposal is completely different, there aren't 
that many substantial changes:


- We changed walrus patterns ('v := p') to AS patterns ('p as v').
- We changed the method of comparison for literals None, False, True to 
use 'is' instead of '=='.

- SyntaxError if an irrefutable case[1] is followed by another case block.
- SyntaxError if an irrefutable pattern[1] occurs on the left of '|', 
e.g. 'x | [x]'.


Is "syntax error" that the right term for it? Maybe it should be 
something different, a subclass of SyntaxError perhaps.


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

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

[Guido van Rossum]

On Thu, Oct 22, 2020 at 10:42 AM MRAB  wrote:

> [Guido]
> > - SyntaxError if an irrefutable case[1] is followed by another case
> block.
> > - SyntaxError if an irrefutable pattern[1] occurs on the left of '|',
> > e.g. 'x | [x]'.
>
> Is "syntax error" that the right term for it? Maybe it should be
> something different, a subclass of SyntaxError perhaps.
>

I think it is a SyntaxError. It is detected without needing to look at the
symbol table, although it is not encoded in the grammar (we probably could,
but it would be very tedious), so it's done during a later stage. We have
many of these (e.g. 'return' outside function, also not encoded in the
grammar).

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

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

[Steven D'Aprano]

On Thu, Oct 22, 2020 at 09:48:54AM -0700, Guido van Rossum wrote:
> After the pattern matching discussion died out, we discussed it with the
> Steering Council. Our discussion ended fairly positive, but there were a
> lot of problems with the text. We decided to abandon the old PEP 622 and
> break it up into three parts:
> 
> - PEP 634: Specification
> - PEP 635: Motivation and Rationale
> - PEP 636: Tutorial

Nice!

(By coincidence, I had stumbled across them a few days ago, and hadn't 
realised that they were new. I hadn't looked at the dates and just 
assumed they were the original proposal.)

I haven't read through them in detail but on broad skimming this looks 
very nice indeed.


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

[Python-Dev] Re: [python-committers] Re: Re: Resignation from Stefan Krah

[Dima Tisnek]

Reading through this thread and the linked comment chains was very educational.
While I'm not involved enough to form an educated opinion, it's good
to see that the wheels of python org are moving.
That being said, I think that "dear stefan" email could have been
written better.
Also +1 on "not punitive" rule from wikipedia, cheers, Ivan!

On Tue, 13 Oct 2020 at 21:05, Thomas Wouters  wrote:
>
>
>
> On Tue, Oct 13, 2020 at 1:32 PM Steven D'Aprano  wrote:
>>
>> On Tue, Oct 13, 2020 at 11:17:33AM +0100, Steve Holden wrote:
>> > Full marks to the SC for transparency. That's a healthy sign that the
>> > community acknowledges its disciplinary processes must also be open to
>> > scrutiny, and rather better than dealing with matters in a Star Council.
>>
>> The SC didn't say anything until Antoine posted an open letter from
>> Stefan to the list.
>
>
> We didn't say anything because, as I mentioned, we wanted to discuss the 
> matter with Stefan before we did so. Also, as I mentioned, we had a 
> back-and-forth with Stefan, and were not aware he had already decided not to 
> comply with our requests or the Code of Conduct. Had he let us know, we 
> would've posted pretty much the same information a few days later.
>
>> There is tension between the requirements of openness and privacy, and I
>> don't have a good answer for where the balance should be. But it seems
>> to me that giving "full marks for transparency" for a decision made
>> behind closed doors that we only found about about because one of the
>> parties was able to announce their ban via a third party is a remarkably
>> soft grade.
>
>
> The SC had already discussed how public to be about this, and we were always 
> going to publish our decision as well as our initial correspondence to 
> Stefan. Posting his replies is not up to us, and posting our replies to him 
> without that context feels unfair and inappropriate. However, the Conduct WG 
> was copied on all the correspondence. This was not backroom justice.
>
> The SC does have to balance openness and privacy, and also fairness, the 
> health of the code base, the health of the community, personal feelings of 
> individual contributors, the perceptions our actions and decisions and 
> silence create for the individuals involved, the other core developers, and 
> the Python community at large. We're also still figuring out the process and 
> standards we want to set for this kind of thing, because it is fairly new to 
> the core developer community.
>
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me 
> spread!
> ___
> 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/4FXU6ZZRLZ6274QSEMXWDXZM6XTKH2W5/
> 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/JQQUTBRIGRUCBMDJI67AOQGEUXEIQWDE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: os.scandir bug in Windows?

[Random832]

On Tue, Oct 20, 2020, at 07:42, Steve Dower wrote:
> On 20Oct2020 0520, Rob Cliffe wrote:
> > On 19/10/2020 12:42, Steve Dower wrote:
> >> On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote:
> >>> TLDR: In os.scandir directory entries, atime is always a copy of 
> >>> mtime rather than the actual access time.
> >>
> >> Correction - os.stat() updates the access time to _now_, while 
> >> os.scandir() returns the last access time without updating it.
> >>
> >> Eryk replied with a deeper explanation of the cause, but fundamentally 
> >> this is what you are seeing.
> >>
> >> Feel free to file a bug, but we'll likely only add a vague note to the 
> >> docs about how Windows works here rather than changing anything. If 
> >> anything, we should probably fix os.stat() to avoid updating the 
> >> access time so that both functions behave the same, but that might be 
> >> too complicated.
> >>
> >> Cheers,
> >> Steve
> > Sorry - what you say does not match the behaviour I observe, which is that
> 
> Yes, I posted a correction already (immediately after sending the first 
> email).

ok, see, the correction you posted doesn't address the part of your claim that 
people are taking issue with, which is that *calling os.stat() causes the atime 
to be set to the time of the call to os.stat()*. This is not the same thing as 
[correctly] saying that "calling os.stat() may return a more up-to-date atime, 
the time of the last read, write, or other operation", and the phrasing 
"updates the access time to _now_" certainly *seemed* unambiguous.

And at this point it's not clear to me whether you understand that people are 
reading your claim this way.

What correction, exactly, do you mean? The post I saw with the word 
"Correction" on it is the one that *makes* the claim people are taking issue 
with.
___
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/O63FMQYOHASHZ33CWBYQMD3H3XYGT5QC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: os.scandir bug in Windows?

[Random832]

On Fri, Oct 23, 2020, at 02:14, Random832 wrote:
> What correction, exactly, do you mean? The post I saw with the word 
> "Correction" on it is the one that *makes* the claim people are taking 
> issue with.

okay, sorry, I see the other correction post now...

My issue I guess was the same as Eryk Sun, it wasn't clear which parts of the 
previous post you were correcting and which (if any) you stood by, since they 
were about the behavior of different parts of the system, so it didn't register 
as a correction to that part when I originally read it.
___
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/U4MZFDDMM4L52DKA6NBB7MKRJJ7QWEOB/
Code of Conduct: http://python.org/psf/codeofconduct/