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

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 th

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

> 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 n

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

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-l

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

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

[Python-Dev] Re: Typing syntax and ecosystem

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 o

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

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] Re: PEP 632: Deprecate distutils module

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 n

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

est 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

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

On 6/30/2020 5:52 AM, Thomas Wouters wrote: > > > On Tue, Jun 30, 2020 at 4:28 AM Giampaolo Rodola' > 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

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

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 us

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

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 p

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

crete 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 wro

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

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. &g

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

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

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

> 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

[Python-Dev] Re: PEP 554 comments

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 advance

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

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

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

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 fragil

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

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

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

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``