[Python-Dev] Re: About PEPs being discussed on Discourse

[Edwin Zimmerman]

On 4/8/22 09:34, Petr Viktorin wrote:
> some cases where Discourse thinks something is a footer and removes it, but 
> IMO they're not huge problems. 

It also has some very good markdown support, so you can post nicely formatted 
code via email.  Mailing list mode with Discourse is almost nicer than a plain 
email list in some ways.
___
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/5CP57WIW3IO2FF2L4Y4EU3RBY5FS2DAB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

[Edwin Zimmerman]

> Christian proposes that having a simpler scope rewrite of it might be nice, 
> but I think disruption to the world and loss of trust in Python would be 
> similar either way.

Please don't remove urllib.  There are mountains of code that rely on it.  A 
much better idea, IMO, would be to add a new modern API to http.client, where 
http functionality properly belongs.  Maybe a function signature like this: 
http.client.get(url, user_agent = None, basic_auth=(None, None),  
custom_headers=None).  That would one line to cover many use basic use cases, 
including user agent and basic auth.
___
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/EV7R35OMQ7QWY7Y744FX7Y7VI7AO5CWX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Dropping out of this list

[Edwin Zimmerman]

On 8/18/21 9:18 PM, Jonathan Goble wrote:
> I am mostly a lurker, but I am also considering unsubscribing if someone 
> doesn't step in and stop the mess

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

[Python-Dev] Re: Problems with dict subclassing performance

[Edwin Zimmerman]

Marco, please calm down.  Your angry emails are not helping you in any way.  
Everyone on this list has had the experience of being misunderstood.  It is 
part of being alive.  There is much more to be gained by leaving your anger 
aside and working constructively towards your goal.  Please, please calm down.

On 8/18/21 4:45 AM, Marco Sulla wrote:
> The silly mistake you all have made is to blame my English error and
> not the unacceptable behaviour of Steven.
> The fact I was really angry with Steven was really clear, since all
> have replied to this. And someone declassed to "sarcasm" the
> insinuation of Steven.
>
> And I've done examples to make it clear it's not possible to not
> understand the sense of my indignation, and the words of Steven cannot
> be declassed (or subclassed?) to sarcasm.
>
> And I will be banned for this! Great! :D
>
> Ah, @Mr. Cannon, I remember the BDFL said in a post "There are too
> many cocks here". I also censored cock, but you simply reprimanded
> him. How much CPython code must one write to be treated humanely? Go
> and ban me permanently please, I'm really sick.
>
> PS: Furthermore, I repeat, you all blame Google:
> https://www.google.com/search?channel=fs&client=ubuntu&q=pretendere+in+inglese
>
> On Wed, 18 Aug 2021 at 09:00, Steve Holden  wrote:
>> Your inflated sense of your own significance is unfortunate, since it 
>> appears to prohibit you from considering the possibility you might have made 
>> a rather silly mistake here, and one which is calculated to move you further 
>> away from your stated goals.
>>
>> Kind regards,
>> Steve
>>
>>
>> On Tue, Aug 17, 2021 at 9:31 PM Marco Sulla  
>> wrote:
>>> On Sun, 15 Aug 2021 at 22:30, Marco Sulla  
>>> wrote:
 Oh, this is enough. The sense of the phrase was very clear and you all
 have understood it. Remarking grammatical errors is a gross violation
 of the Netiquette. I ask __immediately__ the intervent of a moderator,
 even if I quite sure, since I'm mister No One and you are Terry Reed
 and Steven D'Aprano, that this will be against me X-D
>>> Ahahhaahh, call me Marco "Cassandra" Sulla.
>>>
>>> Mr. Cannon, I was sure about your response. Please ban me, it will be
>>> a pleasure to be banned by you for specious reasons. It's your
>>> specialty.
>>>
>>> I want to remember here that you banned me from the Py Forum because I
>>> said "Even a child can understand my code", and you _demanded_ my
>>> excuses. Since I found the accusation ridiculous, I've made my excuses
>>> to all children that do not understand my code. You banned me and even
>>> Steven defended me.
>>>
>>> I've been the moderator for a forum for years, and let me say, you are
>>> not a good moderator. You are hard-mannered. See Tim. He calmed me
>>> down with two posts. You all have to learn from him, as coders,
>>> moderators and human beings.
>>>
>>> That said, please ban me permanently, because I'll _never_ give you my
>>> excuses. What I said is the pure truth.
>>>
>>> PS: as a side note, I started to get downvotes from when this useless
>>> polemic started. Since, I repeat, I have more than 13k reputation on
>>> SO, and since the question had about 20 votes without dirty tricks, as
>>> Steven subtly insinuates, all of this makes me laugh. Do your worst,
>>> you all little men. As a Mister No One, I will be **PROUD** to be
>>> banned as Stephan Krah.
>>>
>>>
>>> On Mon, 16 Aug 2021 at 18:52, Brett Cannon  wrote:


 On Sun, Aug 15, 2021 at 2:55 PM Marco Sulla  
 wrote:
> On Sun, 15 Aug 2021 at 23:33, Tim Peters 
> wrote:ople have said now, including me, they had no idea what
>> you meant.by "I pretend your immediate excuses". It's not a complaint
>> that it's expressed inelegantly, but that they can't make _any_ sense
>> of it. By my count, this is at least the second time you've declined
>> to explain what you meant, but instead implied the person who said
>> they couldn't understand it was being dishonest.
> I repeat, even the worst AI will understand from the context what I
> meant. But let me do a very rude example:

 Rude examples are never necessary and are not acceptable (don't forget we 
 have kids who participate on this mailing list).

 I have referred the whole thread to the Conduct WG so they can settle who 
 was out of line. Otherwise I advise everyone to mute this thread.
>>> ___
>>> 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/BM4AQR347MPNXRDF3FHBYPOOXPHMYQU2/
>>> 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

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[edwin]

April 16, 2021 2:08 PM, "Denis Kotov"  wrote:

> edwin＠211mainstreet.net wrote:
> 
>> Anyone who has done a language change on a project knows that it is a huge 
>> disruption. You need
>> solid justification to make such a change. All I have seen in this thread is 
>> personal opinion.
>> Since this is a personal opinion exchange, I am of the humble opinion that 
>> the personal opinions of
>> core devs matter the most, since a language change would affect them more 
>> than anyone else.
>> April 16, 2021 1:47 PM, redrad...@gmail.com wrote:
>> Guys, the issue is that I most of the time see that somebody used C++ for 
>> one or two times, did not
>> understand it and left with bad taste ...
>> Please, answer me question, if you will go in gym two times, will you get 
>> stop training and say
>> that it does not fit in your life ?
>> ___
>> 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/LWJ4WGWK...
>> Code of Conduct: http://python.org/psf/codeofconduct
> 
> Okay lets try to discuss one by one:
> 1) Readability - less code, most code is hidden by abstraction without losing 
> performance
> In CPython code lots of stuff like Py_INCREF, Py_DECREF .. it could be fixed 
> with C++
> std::shared_ptr<> (RustPython use analog Arc<>)

So every single python extension library would have to be rewritten to handle 
all the new C++ apis?  Sounds like an idea everyone will be very excited about.
___
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/52YMBBM5NWZPYZ7X57O2ETKWD22DLQ3K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[edwin]

Anyone who has done a language change on a project knows that it is a huge 
disruption.  You need solid justification to make such a change.  All I have 
seen in this thread is personal opinion.  Since this is a personal opinion 
exchange, I am of the humble opinion that the personal opinions of core devs 
matter the most, since a language change would affect them more than anyone 
else.

April 16, 2021 1:47 PM, redrad...@gmail.com wrote:

> Guys, the issue is that I most of the time see that somebody used C++ for one 
> or two times, did not
> understand it and left with bad taste ...
> 
> Please, answer me question, if you will go in gym two times, will you get 
> stop training and say
> that it does not fit in your life ?
> ___
> 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/LWJ4WGWKVHG7CLRCSCBNR5ZKUORBMH6Z
> 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/3K3FDADSIFH7WJEKFNNYWFDTCZGZFKBI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Edwin Zimmerman]

On 4/12/2021 6:34 PM, Brett Cannon wrote:
> Had the sentences ended at "confusing" or said something like "I don't think 
> it's as optimal as it could be" or "I think it could be better" are all fine. 
> But saying that the current approach is "arousing or deserving ridicule : 
> extremely silly or unreasonable : absurd, preposterous" as defined by 
> Merriam-Webster  is 
> not necessary to make the point; it could have been phrased in such a way as 
> to be a bit more respectful to those who have put in the time and effort to 
> get things to where they are.
My plea is very simple: that everyone would be a bit more gracious.  Email by 
its very nature does not convey meaning as well as in-person conversation.  As 
Hugh just remarked, the meaning you took from his comments was not the meaning 
he intended to convey.  These misunderstandings seem to be happening more and 
more frequently.  I read this list to understand the direction that Python will 
take in the future, but I have thought numerous times of unsubscribing due to 
all the curt "you said it wrong" responses like the one that triggered my first 
email.

Any way, in the interest of not starting a flame war, I will have nothing more 
to say.
___
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/ETJCGR4ULRYY5WNOLRPULVWMBW4LCY3E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[edwin]

April 12, 2021 4:59 PM, "Brett Cannon"  wrote:

> On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher  wrote:
> 
>>> Message: 1
>>> Date: Sun, 11 Apr 2021 13:31:12 -0700
>>> From: Barry Warsaw 
>>> Subject: [Python-Dev] Re: PEP 647 Accepted
>> 
>>> 
>>> This is something the SC has been musing about, but as it’s not a fully 
>>> formed idea, I’m a little
>> hesitant to bring it up. That said, it’s somewhat relevant: We wonder if it 
>> may be time to in a
>> sense separate the typing syntax from Python’s regular syntax. TypeGuards 
>> are a case where if
>> typing had more flexibility to adopt syntax that wasn’t strictly legal 
>> “normal” Python, maybe
>> something more intuitive could have been proposed. I wonder if the 
>> typing-sig has discussed this
>> possibility (in the future, of course)?
>> 
>> [ munch ]
>> 
>>> 
>>> Agreed. It’s interesting that PEP 593 proposes a different approach to 
>>> enriching the typing
>> system. Typing itself is becoming a little ecosystem of its own, and given 
>> that many Python users
>> are still not fully embracing typing, maybe continuing to tie the typing 
>> syntax to Python syntax is
>> starting to strain.
>> 
>> I would really like to see either "Typed Python" become a different 
>> programming
>> language, or progress to building type checking into the CPython 
>> implementation
>> itself. (Python 4 seems to me the obvious release.) The current halfway 
>> approach
>> is confusing and slightly ridiculous.
> 
> Please don't denigrate the hard work people have put in to even bring forward 
> the idea of typing in
> Python by saying it's "slightly ridiculous".
> 
> -Brett

Aren't people allowed to have their own opinions?  Please, I hate to see this 
list descend further and further into such knee-jerk reactions.  If criticism 
of any current implementation of any construct becomes off-limits is 
automatically classed as "denigrating", there is no reason for this list to 
exist.  You might not agreed with the criticism, but you should at least be 
open to discussion.
___
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/WE2YCV5COQ64VEDJATVGZCMXMJQGZMQ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[Edwin Zimmerman]

On 3/9/2021 8:03 PM, Ivan Pozdeev via Python-Dev wrote:
> countries other than US don't have a modern history of slavery
Putting both politics and programming aside, this isn't quite so:  
https://en.wikipedia.org/wiki/Timeline of abolition of slavery and 
serfdom#1950.E2.80.93present 

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

[Python-Dev] Re: Speeding up CPython

[edwin]

Where is your working code for the first stage?

October 20, 2020 8:53 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
___
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/DXTPGPEKDJTVLEWWMD2JT7HAWD7P6K5E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Hygenic macros PEP.

[edwin]

September 16, 2020 12:24 AM, "Guido van Rossum" mailto:gu...@python.org?to=%22Guido%20van%20Rossum%22%20)> 
wrote:
This may actually address the worry that was expressed that libraries will 
become too dependent on macros, by making it painful to maintain a macro 
processor across many versions. It will serve as a natural deterrent for 
libraries desiring stability.
This exactly addresses the worry that I have in a much better way that the 
command line flag that was mentioned. As long as it is inconvenient enough to 
prevent it from being THE WAY(tm) to code in Python, I have no other objections.

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

[Python-Dev] Re: Hygenic macros PEP.

[edwin]

September 15, 2020 4:31 PM, "Gregory P. Smith" mailto:g...@krypto.org?to=%22Gregory%20P.%20Smith%22%20)> 
wrote:
On Tue, Sep 15, 2020 at 1:27 PM mailto:ed...@211mainstreet.net)> wrote: 
September 15, 2020 4:02 PM, "Daniel Butler" mailto:dabutle...@gmail.com?to=%22daniel%20butler%22%20%3cdabutle...@gmail.com%3E)>
 wrote:
> Users would be encouraged to try it but

> NOT to publish code using it.Thinking out loud, macros could be enabled with 
> a command line flag. Advanced users would know how to use it but others would 
> not. If the macro flag is not enabled it raises a syntax error. Thoughts?
--Thank you!

Daniel Butler
A command line flag would be slightly better. All the documentation warnings in 
the world will not be enough to prevent all the cargo culters from creating 
some of the hardest to read code you ever saw.

If you're talking about a command line flag, I suggest you read the pre-PEP. 
The proposal requires explicit import-like syntax to bring the macro in for 
parsing of code in the duration of the scope of that import. Which is actually 
what you'd want for this kind of thing: explicitly declaring which additional / 
alternate syntax features you use in the code using it. It is similar from the 
existing `from __future__ import behavior` system.

-gps
That may be, but I dislike the thought that 10 years from now the standard 
Stack Overflow answer to "how do I do x in Python" will be "use my magic 5000 
line macro". A command line flag requires more effort, because you need to 
continually retype it. In theory, that little bit of extra effort could help to 
limit macro use to areas where it actually is useful. 

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

[Python-Dev] Re: Hygenic macros PEP.

[edwin]

September 15, 2020 4:02 PM, "Daniel Butler" mailto:dabutle...@gmail.com?to=%22Daniel%20Butler%22%20)>
 wrote:
> Users would be encouraged to try it but

> NOT to publish code using it.
 Thinking out loud, macros could be enabled with a command line flag. Advanced 
users would know how to use it but others would not. If the macro flag is not 
enabled it raises a syntax error. Thoughts?
--Thank you!

Daniel Butler
A command line flag would be slightly better. All the documentation warnings in 
the world will not be enough to prevent all the cargo culters from creating 
some of the hardest to read code you ever saw.

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

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Edwin Zimmerman]

On 9/5/2020 3:59 AM, Emily Bowman wrote:
> On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah  > wrote:
>
>
>
> It is not hyperbolic at all. You can get permissions for a certain set
> of modules (the stdlib), but not for PyPI packages.
>
> Of course the upgrade is not via the network, that is beside the point.
>
>
> If you can update to a breaking Python version, but aren't allowed one single 
> point version of an external module, you have a process problem.
The point remains that these situations exist where it is simply impossible to 
run 'pip install xyz' due to network restrictions.  I know this firsthand 
because I have written software for enforcing total internet blocks.  Pushing 
Python to a pip-only module will preclude its use in such situations.  Again, 
this is not hypothetical.  This is the software world I deal with every day.

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

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Edwin Zimmerman]

On 9/4/2020 6:00 PM, Stefan Krah wrote:
> It is not hyperbolic at all. You can get permissions for a certain set
> of modules (the stdlib), but not for PyPI packages.
>
> Of course the upgrade is not via the network, that is beside the point.
Besides upgrades of existing systems, there are also new installs to consider.  
To totally remove this functionality is force such new systems to continue 
using older versions.  This is not hypothetical hyperbolic in the least.  In 
the software field I work in, I deal with limited internet connectivity all the 
time.  My single biggest software development problem is software dependencies 
that assume a full blown internet connection under all circumstances.  Even in 
2020, that is not always wanted or advisable.

--Edwin Zimmerman

>
> On Fri, Sep 04, 2020 at 02:56:07PM -0700, Emily Bowman wrote:
>> On Fri, Sep 4, 2020 at 10:31 AM Stefan Krah  wrote:
>>
>>> All the time, especially when I'm writing them. I imagine that there's
>>> a huge amount of internal company code that discourages use of pip
>>> installed packages as well.  Or has an air-gapped network in the first
>>> place.
>>>
>> That's wildly hyperbolic; not only will Python retain distutils through
>> 3.11, any "airgapped" build will rest on an existing build that cannot be
>> upgraded, so dependencies are a moot point.
> ___
> 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/7ONUZMXXBFVWZPO6OSY634WNZ2ZC4FSU/
> 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/C4INWCK4QSVVCJDTHCO6R4OKME65VU4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Edwin Zimmerman]

On 6/30/2020 5:52 AM, Thomas Wouters wrote:
>
>
> On Tue, Jun 30, 2020 at 4:28 AM Giampaolo Rodola'  <mailto:g.rod...@gmail.com>> wrote:
>
> This is not about the commit message. It’s way more than that. It's been 
> going on non-stop and got increasingly worse since at least the preparation 
> of the Python elections ~2 years ago. It is not normal what is going on here. 
> People are scared. And it is pretty much guaranteed that this is not gonna be 
> the last occurrence of it. On the horizon we have other language-related 
> controversies like "whitelist" / "blacklist", renaming "master" to "main" in 
> GIT, and who knows what else (maybe "whitespace"? or @property?).
>
>
> I don't have words for the irony of complaining about changing words while 
> objecting to the wording in a commit message. Especially considering the 
> commit message isn't nearly as visible as the places that people have 
> actually been fixing things like master/slave.
>  
>
> And every time that's gonna happen the motivation is gonna be about white 
> supremacy/privilege/guilt etc. Because it's always about that, and we'll be 
> having this discussion once again. On one hand Python gladly takes our 
> patches and everything is smooth,
>
>
> I'm not sure who 'our' is in this sentence, but I'm certainly not glad Python 
> ever took any of your patches. No contribution to Python outweighs the harm 
> you're doing by espousing and advocating for these views. This kind of 
> sentiment scares away a lot of valuable contributors -- I know this because 
> *they have told me* -- and that you're doing it while arguing against a 
> change to a different (unintentional but still harmful) gatekeeping mechanism 
> just makes it so much worse.
Note to self:  It's kind of hard to convince the opposition to take an honest 
look at my viewpoint when I start by attacking them personally.

To everyone else:  I saw this flame war coming the minute I read the original 
post.  Unfortunately, it seems no longer possible to discuss this subject in 
any reasonable way.  Everyone seems to have forgotten that you can attack an 
idea without attacking the person presenting it.  Moderators, please, can this 
thread just be stopped?

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Edwin Zimmerman]

On 6/25/2020 3:55 AM, Kyle Stanley wrote:
> 2) Regarding the constant value pattern semantics, I'm okay with the
> usage of the "." in general, but I completely agree with several
> others that it's rather difficult to read when there's a leading
> period with a single word, e.g. ".CONSTANT". To some degree, this
> could probably be less problematic with some reasonably good syntax
> highlighting to draw attention to the leading period.
>
> However, I don't think it should be at all necessary for people to
> rely on syntax highlighting to be able to clearly see something that's
> part of a core Python language feature. It seems especially
> detrimental for those with visual impairment. As someone with
> relatively poor eye-sight who typically has to blow up the font size
> for my code to be readable (and often finds syntax highlighting to be
> distracting), I'm not really looking forward to squinting for missed
> leading periods when it was intended to refer to a constant reference.
> Even if it's a relatively uncommon case, with a core feature, it's
> bound to happen enough to cause some headaches.

A missing . is exactly the type of mistake I tend to make. It is also the type 
of mistake that I could stare at endlessly and not notice.  Surely there could 
be a much more obvious way of doing things.

Other than this . issue, the PEP is great!  I look forward to using match.

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

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

[Edwin]

That's so, but threads have this problem too.  I don't think this discussion is 
about finding a "perfect" solution or an "ultimate" way of doing things, rather 
it is about the varying opinions on certain design tradeoffs.  If I'm satisfied 
that subinterpreters are the correct solution to my particular need, why 
shouldn't I have the privilege of doing so?



--Edwin

- Original Message -
From: Guido van Rossum (gu...@python.org)
Date: 06/16/20 13:30
To: Python Dev (python-dev@python.org)
Subject: [Python-Dev] Re: Should we be making so many changes in pursuit of PEP 
554?


Has anybody brought up the problem yet that if one subinterpreter encounters a 
hard crash (say, it segfaults due to a bug in a C extension module), all 
subinterpreters active at that moment in the same process are likely to lose 
all their outstanding work, without a chance of recovery?

(Of course once we have locks in shared memory, a crashed process leaving a 
lock behind may also screw up everybody else, though perhaps less severely.)
--


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

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

[Edwin Zimmerman]

On 6/12/2020 2:17 PM, Chris Angelico wrote:
> On Sat, Jun 13, 2020 at 3:50 AM Edwin Zimmerman  
> wrote:
>> My previous timings were slightly inaccurate, as they compared spawning 
>> processes on Windows to forking on Linux.  Also, I changed my timing code to 
>> run all process synchronously, to avoid hitting resource limits.
>>
>> Updated Windows (Windows 7 this time, on a four core processor):
>>
>>>>> timeit.timeit('x=multiprocessing.Process(target=exit);x.start();x.join()',
>>>>>  number=1000,globals = globals())
>> 84.7111053659259
>>
> Thanks, I was actually going to ask about joining the processes, since
> you don't really get a good indication of timings from asynchronous
> operations like that. Another interesting data point is that starting
> and joining in batches makes a fairly huge difference to performance,
> at least on my Linux system. Starting with your example and rescaling
> the number by ten to compensate for performance differences:
>
>>>> timeit.timeit('x=multiprocessing.Process(target=exit);x.start();x.join()', 
>>>> number=1,globals = globals())
> 14.261007152497768
>
> Just for completeness and consistency, confirmed that adding a list
> comp around it doesn't change the timings:
>
>>>> timeit.timeit('xx=[multiprocessing.Process(target=exit) for _ in 
>>>> range(1)];[x.start() for x in xx];[x.join() for x in xx]', 
>>>> number=1,globals = globals())
> 14.030426062643528
>
> But doing a hundred at a time and then joining them all cuts the time in half!
>
>>>> timeit.timeit('xx=[multiprocessing.Process(target=exit) for _ in 
>>>> range(100)];[x.start() for x in xx];[x.join() for x in xx]', 
>>>> number=100,globals = globals())
> 5.470761131495237
>
> The difference is even more drastic with spawn, although since it's
> slower, I also lowered the number of iterations.
>
>>>> ctx = multiprocessing.get_context('spawn')
>>>> timeit.timeit('x=ctx.Process(target=exit);x.start();x.join()', 
>>>> number=1000,globals = globals())
> 40.82687543518841
>>>> timeit.timeit('xx=[ctx.Process(target=exit) for _ in 
>>>> range(100)];[x.start() for x in xx];[x.join() for x in xx]', 
>>>> number=10,globals = globals())8.566341979429126
> 8.566341979429126
>
> Would be curious to know if that's the same on Windows.
Yea, it's the same.  Watch your cpu utilization, and you will realize that your 
list comprehension is parallelizing the process startups.
> ChrisA
> ___
> 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/YFRM3LNO37B5JXNYPO2T7CAVYQRGAYES/
> 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/CICKBHTOAUOW3ARZ2Z4AYAKOWVGKWKVU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

[Edwin Zimmerman]

My previous timings were slightly inaccurate, as they compared spawning 
processes on Windows to forking on Linux.  Also, I changed my timing code to 
run all process synchronously, to avoid hitting resource limits.

 

Updated Windows (Windows 7 this time, on a four core processor):

>>> timeit.timeit('x=multiprocessing.Process(target=exit);x.start();x.join()', 
>>> number=1000,globals = globals())

84.7111053659259

 

Updated Linux with spawn (single core processor):

>>> ctx = multiprocessing.get_context('spawn')

>>> timeit.timeit('x=ctx.Process(target=exit);x.start();x.join()', 
>>> number=1000,globals = globals())

60.01154333699378

 

Updated Linux with fork:
>>> timeit.timeit('x=multiprocessing.Process(target=exit);x.start();x.join()', 
>>> number=1000,globals = globals())

4.402019854984246

 

Compare this to subinterpreters on my linux machine:

>>> timeit.timeit('s=_xxsubinterpreters.create();_xxsubinterpreters.destroy(s)',number=1000,
>>>  globals=globals())

13.47043095799745

 

This shows that is speed is all that matters, multiprocessing comes out way 
ahead of subinterpreters on linux, but way behind on Windows.

I need to time subinterpreters on Windows yet for the full picture, but that 
will be tomorrow till I get that done.

 

--Edwin

 

From: Emily Bowman [mailto:silverback...@gmail.com] 
Sent: Friday, June 12, 2020 12:44 PM
To: Mark Shannon 
Cc: Python Dev 
Subject: [Python-Dev] Re: My take on multiple interpreters (Was: Should we be 
making so many changes in pursuit of PEP 554?)

 

On Fri, Jun 12, 2020 at 7:19 AM Mark Shannon mailto:m...@hotpy.org> > wrote:

Hi Edwin,

Thanks for providing some concrete numbers.
Is it expected that creating 100 processes takes 6.3ms per process, but 
that creating 1000 process takes 40ms per process? That's over 6 times 
as long in the latter case.

Cheers,
Mark.

On 12/06/2020 11:29 am, Edwin Zimmerman wrote:
> On 6/12/2020 6:18 AM, Edwin Zimmerman wrote:
>> On 6/12/2020 5:08 AM, Paul Moore wrote:
>>> On Fri, 12 Jun 2020 at 09:47, Mark Shannon >> <mailto:m...@hotpy.org> > wrote:
>>>> Starting a new process is cheap. On my machine, starting a new Python
>>>> process takes under 1ms and uses a few Mbytes.
>>> Is that on Windows or Unix? Traditionally, process creation has been
>>> costly on Windows, which is why threads, and in-process solutions in
>>> general, tend to be more common on that platform. I haven't done
>>> experiments recently, but I do tend to avoid multiprocess-type
>>> solutions on Windows "just in case". I know that evaluating a new
>>> feature based on unsubstantiated assumptions informed by "it used to
>>> be like this" is ill-advised, but so is assuming that everything will
>>> be OK based on experience on a single platform :-)
>> Here's a test on Windows 10, 4 logical cpus, 8 GB of ram:
>>
>>>>> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=100,
>>>>>  globals=globals())
>> 0.62975287
>>>>> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=1000,
>>>>>  globals=globals())
>> 40.28172119964
>>
>> Or this way:
>>>>> timeit.timeit("""os.system('python.exe -c "exit()"')""",number=100, 
>>>>> globals=globals())
>> 17.46125929995
>>
>> --Edwin
> For comparison, on a single core linux cloud server with 512 mb of ram:
> 
> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=100, 
> globals=globals())
> 0.354354709998006
> 
> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=1000, 
> globals=globals())
> 3.847851719998289
> 
> So yeah, process creation is still rather costly on Windows.

 

I was wondering that too, some tests show that process creation/destruction 
starts to seriously bog down after a few hundred in a row. I guess it's hitting 
some resource limits it has to clean up, though creating hundreds of processes 
at once sounds like an antipattern that doesn't really deserve too much 
consideration. It would be rare that fork is more than a negligible part of any 
workload. (With A/V on, though, it's _much_ slower out the gate. I'm seeing 
over 100ms per process with Kaspersky running.)

 

Em

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

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

[Edwin Zimmerman]

On 6/12/2020 6:18 AM, Edwin Zimmerman wrote:
> On 6/12/2020 5:08 AM, Paul Moore wrote:
>> On Fri, 12 Jun 2020 at 09:47, Mark Shannon  wrote:
>>> Starting a new process is cheap. On my machine, starting a new Python
>>> process takes under 1ms and uses a few Mbytes.
>> Is that on Windows or Unix? Traditionally, process creation has been
>> costly on Windows, which is why threads, and in-process solutions in
>> general, tend to be more common on that platform. I haven't done
>> experiments recently, but I do tend to avoid multiprocess-type
>> solutions on Windows "just in case". I know that evaluating a new
>> feature based on unsubstantiated assumptions informed by "it used to
>> be like this" is ill-advised, but so is assuming that everything will
>> be OK based on experience on a single platform :-)
> Here's a test on Windows 10, 4 logical cpus, 8 GB of ram:
>
>>>> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=100,
>>>>  globals=globals())
> 0.62975287
>>>> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=1000,
>>>>  globals=globals())
> 40.28172119964
>
> Or this way:
>>>> timeit.timeit("""os.system('python.exe -c "exit()"')""",number=100, 
>>>> globals=globals())
> 17.46125929995
>
> --Edwin
For comparison, on a single core linux cloud server with 512 mb of ram:

timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=100, 
globals=globals())
0.354354709998006

timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=1000, 
globals=globals())
3.847851719998289

So yeah, process creation is still rather costly on Windows.
___
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/BLBNMZXKYDKRDYRFNEHYPMNHNFMOU4WG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

[Edwin Zimmerman]

On 6/12/2020 5:08 AM, Paul Moore wrote:
> On Fri, 12 Jun 2020 at 09:47, Mark Shannon  wrote:
>> Starting a new process is cheap. On my machine, starting a new Python
>> process takes under 1ms and uses a few Mbytes.
> Is that on Windows or Unix? Traditionally, process creation has been
> costly on Windows, which is why threads, and in-process solutions in
> general, tend to be more common on that platform. I haven't done
> experiments recently, but I do tend to avoid multiprocess-type
> solutions on Windows "just in case". I know that evaluating a new
> feature based on unsubstantiated assumptions informed by "it used to
> be like this" is ill-advised, but so is assuming that everything will
> be OK based on experience on a single platform :-)
Here's a test on Windows 10, 4 logical cpus, 8 GB of ram:

>>> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=100,
>>>  globals=globals())
0.62975287
>>> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=1000,
>>>  globals=globals())
40.28172119964

Or this way:
>>> timeit.timeit("""os.system('python.exe -c "exit()"')""",number=100, 
>>> globals=globals())
17.46125929995

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

[Python-Dev] Should we be making so many changes in pursuit of PEP 554?

[Edwin Zimmerman]

> Hi,
> 
> There have been a lot of changes both to the C API and to internal
> implementations to allow multiple interpreters in a single O/S process.
> 
> These changes cause backwards compatibility changes, have a negative
> performance impact, and cause a lot of churn.
> 
> While I'm in favour of PEP 554, or some similar model for parallelism in
> Python, I am opposed to the changes we are currently making to support it.
> 
> 
> What are sub-interpreters?
> --
> 
> A sub-interpreter is a logically independent Python process which
> supports inter-interpreter communication built on shared memory and
> channels. Passing of Python objects is supported, but only by copying,
> not by reference. Data can be shared via buffers.
> 
> 
> How can they be implemented to support parallelism?
> ---
> 
> There are two obvious options.
> a) Many sub-interpreters in a single O/S process. I will call this the
> many-to-one model (many interpreters in one O/S process).
> b) One sub-interpreter per O/S process. This is what we currently have
> for multiprocessing. I will call this the one-to-one model (one
> interpreter in one O/S process).
> 
> There seems to be an assumption amongst those working on PEP 554 that
> the many-to-one model is the only way to support sub-interpreters that
> can execute in parallel.
> This isn't true. The one-to-one model has many advantages.
> 
> 
> Advantages of the one-to-one model
> --
> 
> 1. It's less bug prone. It is much easier to reason about code working
> in a single address space. Most code assumes

I'm curious where reasoning about address spaces comes into writing Python 
code?  I can't say that address space has ever been a
concern to me when coding in Python.

> 2. It's more secure. Separate O/S processes provide a much stronger
> boundary between interpreters. This is why some browsers use separate
> processes for browser tabs.
> 
> 3. It can be implemented on top of the multiprocessing module, for
> testing. A more efficient implementation can be developed once
> sub-interpreters prove useful.
> 
> 4. The required changes should have no negative performance impact.
> 
> 5. Third party modules should continue to work as they do now.
> 
> 6. It takes much less work :)
> 
> 
> Performance
> ---
> 
> Creating O/S processes is usually considered to be slow. Whilst
> processes are undoubtedly slower to create than threads, the absolute
> time to create a process is small; well under 1ms on linux.
> 
> Creating a new sub-interpreter typically requires importing quite a few
> modules before any useful work can be done.
> The time spent doing these imports will dominate the time to create an
> O/S process or thread.
> If sub-interpreters are to be used for parallelism, there is no need to
> have many more sub-interpreters than CPU cores, so the overhead should
> be small. For additional concurrency, threads or coroutines can be used.
> 
> The one-to-one model is faster as it uses the hardware for interpreter
> separation, whereas the many-to-one model must use software.
> Process separation by the hardware virtual memory system has zero cost.
> Separation done in software needs extra memory reads when doing
> allocation or deallocation.
> 
> Overall, for any interpreter that runs for a second or more, it is
> likely that the one-to-one model would be faster.
> 
> 
> Timings of multiprocessing & threads on my machine (6-core 2019 laptop)
> ---
> 
> #Threads
> 
> def foo():
>  pass
> 
> def spawn_and_join(count):
>  threads = [ Thread(target=foo, args=()) for _ in range(count) ]
>  for t in threads:
>  t.start()
>  for t in threads:
>  t.join()
> 
> spawn_and_join(1000)
> 
> # Processes
> 
> def spawn_and_join(count):
>  processes = [ Process(target=foo, args=()) for _ in range(count) ]
>  for p in processes:
>  p.start()
>  for p in processes:
>  p.join()
> 
> spawn_and_join(1000)
> 
> Wall clock time for threads:
> 86ms. Less than 0.1ms per thread.
> 
> Wall clock time for processes:
> 370ms. Less than 0.4ms per process.
> 
> Processes are slower, but plenty fast enough.
> 
> 
> 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-
> d...@python.org/message/5YNWDIYECDQDYQ7IFYJS6K5HUDUAWTT6/
> 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 
ht

[Python-Dev] Re: PEP 554 comments

[Edwin Zimmerman]

On Tuesday, April 21, 2020 9:20 AM Victor Stinner [mailto:vstin...@python.org] 
wrote
> Hi,
> 
> Le sam. 18 avr. 2020 à 19:16, Antoine Pitrou  a écrit :
> > Mostly, I hope that by making the
> > subinterpreters functionality available to pure Python programmers
> > (while it was formally an advanced and arcane part of the C API), we
> > will spur of bunch of interesting third-party experimentations,
> > including possibilities that we on python-dev have not thought about.
> > (...)
> > * I think the module should indeed be provisional.  Experimentation may
> >   discover warts that call for a change in the API or semantics.  Let's
> >   not prevent ourselves from fixing those issues.
> 
> Would it make sense to start by adding the module as a private
> "_subinterpreters" module but document it? The "_" prefix would be a
> reminder that "hey! it's experimental, there is a no backward
> compatibility warranty there".
> 
> We can also add a big warning in the documentation.
> 
> Victor

 What about requiring "from __future__ import subinterpreters" to use this?
According to the docs, the purpose of __future__ is "to document when 
incompatible changes were introduced", and it does seem that this would be an 
incompatible change for some C extensions.
--Edwin
___
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/N357K6CNGLKWILZYTZUTCIHSS2IEEEXG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

[Edwin Zimmerman]

On 4/20/2020 7:33 PM, Nathaniel Smith wrote:
> On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman  
> wrote:
>> On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
>>> We already have robust support for threads for low-isolation and
>>> subprocesses for high-isolation. Can you name some use cases where
>>> neither of these are appropriate and you instead want an in-between
>>> isolation – like subprocesses, but more fragile and with odd edge
>>> cases where state leaks between them?
>> I don't know if this has been mentioned before or not, but I'll bring it up 
>> now: massively concurrent networking code on Windows.  Socket connections 
>> could be passed off from the main interpreter to sub-interpreters for 
>> concurrent processing that simply isn't possible with the global GIL 
>> (provided the GIL actually becomes per-interpreter).  On *nix you can fork, 
>> this would give CPython on Windows similar capabilities.
> Both Windows and Unix have APIs for passing sockets between related or
> unrelated processes -- no fork needed. On Windows, it's exposed as the
> socket.share method:
> https://docs.python.org/3/library/socket.html#socket.socket.share
>
> The APIs for managing and communicating between processes are
> definitely not the most obvious or simplest to use, but they're very
> mature and powerful, and it's a lot easier to wrap them up in a
> high-level API than it is to effectively reimplement process
> separation from scratch inside CPython.
>
> -n
+1 on not being most obvious or simplest to use.  Not only that, but to use it 
you have to write Windows-specific code.  PEP 554 would provide a uniform, 
cross-platform capability that I would choose any day over a random pile of 
os-specific hacks.
--Edwin
___
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/PVLDRLGQ24OV6VM5OR3OFF7HEQY245BP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

[Edwin Zimmerman]

On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
> We already have robust support for threads for low-isolation and
> subprocesses for high-isolation. Can you name some use cases where
> neither of these are appropriate and you instead want an in-between
> isolation – like subprocesses, but more fragile and with odd edge
> cases where state leaks between them?
I don't know if this has been mentioned before or not, but I'll bring it up 
now: massively concurrent networking code on Windows.  Socket connections could 
be passed off from the main interpreter to sub-interpreters for concurrent 
processing that simply isn't possible with the global GIL (provided the GIL 
actually becomes per-interpreter).  On *nix you can fork, this would give 
CPython on Windows similar capabilities.
___
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/MNC6BO7GC6RZA5TI7UTPHJXYDQLQY7DA/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

[Edwin Zimmerman]

On Tuesday, May 21, 2019 12:30 PM Glenn Linderman wrote

On 5/20/2019 2:20 PM, Christian Heimes wrote:
On 20/05/2019 23.12, Andrew Svetlov wrote:
socketserver.py is also questionable
I briefly though about the module, but didn't consider it for removal. The 
http.server, xmlrpc.server, and logging configuration
server are implemented on top of the socketserver. I don't want to remove the 
socketserver module without a suitable replacement for
http.server in the standard library.

But http.server could be on the remove list too... it gets mighty little 
support, has very little functionality, and implements a
CGI interface (although that also has very little functionality), and you have 
the CGI tools on the remove list, rendering the CGI
interface implemented by http.server less easily usable.

Further, it doesn't directly support https:, and browsers are removing/reducing 
support for http:.
All the same, I’d hate to see http.server leave.  It’s doubtful that anyone 
uses the thing for a production server, but I use it
all the time for low-volume development stuff on Windows.
<>___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 2nd version

[Edwin Zimmerman]

On Thursday, May 02, 2019 Victor Stinner  wrote:
>

According to this

> * ``run_command`` (``wchar_t*``): ``-c COMMAND`` argument
> * ``run_filename`` (``wchar_t*``): ``python3 SCRIPT`` argument
> * ``run_module`` (``wchar_t*``): ``python3 -m MODULE`` argument


this
> ``-c COMMAND````run_module = COMMAND``
should read "run_command = COMMAND".  Typo, not?


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com