Re: [Python-Dev] PEP 594: update 1

Hi, thanks for the work on this proposal, I think this is at least a tip of the iceberg and a good start for the bigger question of how the stdlib should evolve.. I think that the PEP should include an idea of what should happen if existing stdlib pieces depend on this deprecated modules. For

Re: [Python-Dev] PEP 558: Defined semantics for locals()

That's a good fine point that the PEP could call out, but just adding "dynamic" in front of "snapshot" everywhere doesn't tell me any of that. Given that the code calling locals() must of necessity live in the same function body (except for the special case of trace functions), I don't think that

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sat, May 25, 2019, 07:38 Guido van Rossum wrote: > This looks great. > > I only have two nits with the text. > > First, why is the snapshot called a "dynamic snapshot"? What exactly is > dynamic about it? > It's dynamic in that it can spontaneously change when certain other events happen.

Re: [Python-Dev] PEP 594: update 1

Please start a new thread if you want to continue discussing what will come after Python 3.9. On Fri., May 24, 2019, 22:45 Glenn Linderman, wrote: > On 5/24/2019 9:09 PM, Random832 wrote: > > On Thu, May 23, 2019, at 15:27, Steve Holden wrote: > > Besides which, it would be lovely to have a

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On 5/25/2019 10:36 AM, Guido van Rossum wrote: This looks great. I agree. I understand and have tried to explain normal operation multiple times. The proposed new doc looks better than anything I ever wrote. (I never even thought about locals() with tracing on.) The improved clarity

Re: [Python-Dev] PEP 558: Defined semantics for locals()

This looks great. I only have two nits with the text. First, why is the snapshot called a "dynamic snapshot"? What exactly is dynamic about it? Second, you use the word "mapping" a lot. Would you mind changing that to "mapping object" in most places? Especially in the phrase "each call to

Re: [Python-Dev] PEP 558: Defined semantics for locals()

Hi, On Thu, 23 May 2019 at 17:28, Steve Dower wrote: > On 23May2019 0636, Nick Coghlan wrote: > > However, I think the PR does show that the proposed technique can be > > implemented without too much additional code complexity, and will > > hopefully be adaptable for all implementations that

Re: [Python-Dev] PEP 594: update 1

On 5/24/2019 9:09 PM, Random832 wrote: On Thu, May 23, 2019, at 15:27, Steve Holden wrote: Besides which, it would be lovely to have a major release that didn't involve any pain at all for the majority of users! Our erstwhile BDFL always eschewed two-digit version identifiers- due to the

Re: [Python-Dev] PEP 594: update 1

On Thu, May 23, 2019, at 15:27, Steve Holden wrote: > Besides which, it would be lovely to have a major release that didn't > involve any pain at all for the majority of users! > > Our erstwhile BDFL always eschewed two-digit version identifiers- due > to the possibility for confusion about

Re: [Python-Dev] PEP 594 -- Bundling libraries?

On Fri, May 24, 2019 at 12:20 AM Inada Naoki wrote: > When removing libraries from stdlib, can we bundle > removed libraries and install it like ensurepip does? > I think that would require people picking those modules up and maintaining them. But even then I don't know how easy it would be to

Re: [Python-Dev] PEP 594: update 1

On Thu, May 23, 2019 at 5:45 PM Steven D'Aprano wrote: > On Thu, May 23, 2019 at 02:06:13PM -0700, Brett Cannon wrote: > > On Wed, May 22, 2019 at 1:23 PM Sean Wallitsch < > > sean.wallit...@dreamworks.com> wrote: > > > > > My apologies for that oversight. My understanding is that many of the >

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On 23May2019 2355, Steven D'Aprano wrote: I don't know if this is a good idea or a terrible idea or somewhere in between, so I'm throwing it out to see if anyone likes it. Let's add a third option to PEP 594 between "keep" and "remove": explicitly flagging a module as unmaintained. Unmaintained

[Python-Dev] PEP 594 -- Bundling libraries?

When removing libraries from stdlib, can we bundle removed libraries and install it like ensurepip does? Ruby does similar thing, called "Gemification". See https://rubykaigi.org/2017/presentations/hsbt.html When people don't use venv, scripts importing nntplib or aifc runs correctly. When

[Python-Dev] PEP 594 - a proposal for unmaintained modules

I don't know if this is a good idea or a terrible idea or somewhere in between, so I'm throwing it out to see if anyone likes it. Let's add a third option to PEP 594 between "keep" and "remove": explicitly flagging a module as unmaintained. Unmaintained modules: - will raise a warning when

Re: [Python-Dev] PEP 594: update 1

Steve Dower wrote: We need to make it more clear somehow that Python uses series.major.minor.micro versioning, not SemVer. We could also do with deciding what the "series" part is really supposed to be for. At the moment it seems to be "we change it when the major number gets up to 9, or we

Re: [Python-Dev] PEP 594: update 1

On Thu, May 23, 2019 at 02:06:13PM -0700, Brett Cannon wrote: > On Wed, May 22, 2019 at 1:23 PM Sean Wallitsch < > sean.wallit...@dreamworks.com> wrote: > > > My apologies for that oversight. My understanding is that many of the > > methods present in aifc depend heavily on audioop for reading

Re: [Python-Dev] PEP 594: update 1

On Wed, May 22, 2019 at 1:23 PM Sean Wallitsch < sean.wallit...@dreamworks.com> wrote: > My apologies for that oversight. My understanding is that many of the > methods present in aifc depend heavily on audioop for reading and writing. > But are people using audioop directly? This shifts whether

[Python-Dev] PEP 595: Improving bugs.python.org

eport is also use to generate statistics and graphs that can be used to gain new insights [#]_. * There are currently two mailing lists where Roundup posts new tracker issues and all messages respectively: new-bugs-announce [#]_ and python-bugs-list [#]_. A new system will need to be devel

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

What would _really_ help is getting the groups that maintain each dead parrot to collaborate on a "Python Legacy release" that adds back anything with a maintainer to the stdlib of the current Python version. Even that will demand large resources, and if it's to be organised in a way that doesn't

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

. I think reactions to individual module peps will give a > better indication of if it's a used module or not. > > > -Original Message- > > From: Python-Dev > list=sdamon@python.org> On Behalf Of Christian Heimes > > Sent: Monday, May 20, 2019 4:15 PM >

Re: [Python-Dev] PEP 594: update 1

Besides which, it would be lovely to have a major release that didn't involve any pain at all for the majority of users! Our erstwhile BDFL always eschewed two-digit version identifiers- due to the possibility for confusion about collating sequence, I beleive.. We should honour his preferences

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

On May 20, 2019, at 13:15, Christian Heimes wrote: > > here is the first version of my PEP 594 to deprecate and eventually remove > modules from the standard library. The PEP started last year with talk during > the Python Language Summit 2018, https://lwn.net/Articles/755229/. > > The PEP

Re: [Python-Dev] PEP 594: update 1

On 23May2019 0947, Anders Munch wrote: Fra: Paul Moore [mailto:p.f.mo...@gmail.com]: A major version change serves as a heads up that something is going on and you need to check the consequences before upgrading. Python's backward compatibility policy allows breaking changes between versions

Re: [Python-Dev] PEP 594: update 1

Fra: Paul Moore [mailto:p.f.mo...@gmail.com]: > > A major version change serves as a heads up that something is going on and > > you need to check the consequences before upgrading. > Python's backward compatibility policy allows breaking changes between > versions X.Y and X.Y+1 (with a suitable

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

ay, May 20, 2019 4:15 PM To: Python Dev Subject: [Python-Dev] PEP 594: Removing dead batteries from the standard library Hi, here is the first version of my PEP 594 to deprecate and eventually remove modules from the standard library. The PEP started last year with talk during the Python Langu

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On 23May2019 0636, Nick Coghlan wrote: However, I think the PR does show that the proposed technique can be implemented without too much additional code complexity, and will hopefully be adaptable for all implementations that emulate the frame API at all. Much excitement! One of the things I

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Wed, 22 May 2019 at 00:51, Nick Coghlan wrote: > P.S. I'm away this weekend, so I expect the reference implementation > to be done late next week, and I'd be submitting the PEP to Nathaniel > for formal pronouncement at that point. However, I'm posting this > thread now so that there's more

Re: [Python-Dev] PEP 594: update 1

On Thu, 23 May 2019 at 14:25, Anders Munch wrote: > A major version change serves as a heads up that something is going on and > you need to check the consequences before upgrading. Python's backward compatibility policy allows breaking changes between versions X.Y and X.Y+1 (with a suitable

Re: [Python-Dev] PEP 594: update 1

Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne af Terry Reedy: >> Deprecation schedule >> > > I think it worth adding that some modules were deprecated years ago but kept > until after 2.7 end-of-life to ease 3.x transition. Removing modules

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

day, May 20, 2019 4:15 PM > To: Python Dev > Subject: [Python-Dev] PEP 594: Removing dead batteries from the standard > library > > Hi, > > here is the first version of my PEP 594 to deprecate and eventually remove > modules from the standard library. The PEP started la

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

On 23/05/2019 02.58, Steven D'Aprano wrote: > On Wed, May 22, 2019 at 01:31:18PM +0200, Christian Heimes wrote: >> On 22/05/2019 12.19, Steven D'Aprano wrote: >>> I don't think this PEP should become a document about "Why you should >>> use PAM". I appreciate that from your perspective as a Red

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

On 5/22/2019 4:09 AM, Christian Heimes wrote: On 22/05/2019 01.11, Glenn Linderman wrote: On 5/21/2019 2:00 PM, Nathaniel Smith wrote: On Tue, May 21, 2019 at 10:43 AM Glenn Linderman wrote: After maintaining my own version of http.server to fix or workaround some of its deficiencies for

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

On Wed, May 22, 2019 at 01:31:18PM +0200, Christian Heimes wrote: > On 22/05/2019 12.19, Steven D'Aprano wrote: > > I don't think this PEP should become a document about "Why you should > > use PAM". I appreciate that from your perspective as a Red Hat security > > guy, you want everyone to use

Re: [Python-Dev] PEP 594: update 1

My apologies for that oversight. My understanding is that many of the methods present in aifc depend heavily on audioop for reading and writing. On Wed, May 22, 2019 at 12:35 PM Nathaniel Smith wrote: > On Wed, May 22, 2019, 12:14 Sean Wallitsch > wrote: > >> Dear python-dev, >> >> I'm writing

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

On Wed, May 22, 2019, 04:32 Christian Heimes wrote: > On 22/05/2019 12.19, Steven D'Aprano wrote: > > I don't think this PEP should become a document about "Why you should > > use PAM". I appreciate that from your perspective as a Red Hat security > > guy, you want everyone to use best practices

Re: [Python-Dev] PEP 594: update 1

On Wed, May 22, 2019, 12:14 Sean Wallitsch wrote: > Dear python-dev, > > I'm writing to provide some feedback on PEP-594, primarily the proposed > deprecation and reason for the removal of the aifc and audioop libraries. > > The post production film industry continues to make heavy use of AIFFs,

Re: [Python-Dev] PEP 594: update 1

Dear python-dev, I'm writing to provide some feedback on PEP-594, primarily the proposed deprecation and reason for the removal of the aifc and audioop libraries. The post production film industry continues to make heavy use of AIFFs, as completely uncompressed audio is preferred. Support for

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

Between this discussion and Steve Dower's recently referenced blog post at https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/from which I quote below: It’s been widely known for many years that Windows is the only mainstream operating system that does not include

Re: [Python-Dev] PEP 594: update 1

On Wed., May 22, 2019, 03:13 Antoine Pitrou, wrote: > On Tue, 21 May 2019 17:44:16 -0700 > Brett Cannon wrote: > > > > > > So I should never have added those tests and then we wouldn't be > talking > > > about removing nntplib. > > > > > > > Not necessarily. I suspect it still would have been

Re: [Python-Dev] PEP 594: update 1

Christian, Please don't touch nntplib. Also I think telnetlib should stay. On Wed, May 22, 2019 at 5:44 AM Berker Peksağ wrote: > On Tue, May 21, 2019 at 7:11 PM Christian Heimes > wrote: > > > > On 21/05/2019 17.31, Antoine Pitrou wrote: > > > > > > As I said, if the main annoyance with

Re: [Python-Dev] PEP 590 (Vectorcall) discussion

Discussion on PEP 590 (Vectorcall) has been split over several PRs, issues and e-mails, so let me post an update. I am planning to approve PEP 590 with the following changes, if Mark doesn't object to them: * https://github.com/python/peps/pull/1064 (Mark the main API as private to allow

Re: [Python-Dev] PEP 594: discussion-to discuss.python.org

On Wed, 22 May 2019 at 13:28, Christian Heimes wrote: > > Please use > https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 > for feedback and discussion. > > Thank you, > Christian Out of curiosity, why? There's been a lot of useful discussion here - why

Re: [Python-Dev] PEP 594: update 1

On Tue, May 21, 2019 at 7:11 PM Christian Heimes wrote: > > On 21/05/2019 17.31, Antoine Pitrou wrote: > > > > As I said, if the main annoyance with nntplib is the sporadic test > > failures, then the relevant tests can be disabled on CI. > > > > NNTP itself is still used, even if less and less.

Re: [Python-Dev] PEP 594: update 1

On 22/05/2019 02.44, Brett Cannon wrote: > It also doesn't help that no one is listed in the experts index for the > module either.. Excellent point! The PEP now lists the presence / absence of experts. Christian ___ Python-Dev mailing list

[Python-Dev] PEP 594: discussion-to discuss.python.org

Please use https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 for feedback and discussion. Thank you, Christian ___ Python-Dev mailing list Python-Dev@python.org

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

On 22/05/2019 06.59, Stephen J. Turnbull wrote: > Christian Heimes writes: > > > It's all open source. It's up to the Python community to adopt > > packages and provide them on PyPI. > > > > Python core will not maintain and distribute the packages. I'll > > merely provide a repository with

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

On 22/05/2019 12.19, Steven D'Aprano wrote: > I don't think this PEP should become a document about "Why you should > use PAM". I appreciate that from your perspective as a Red Hat security > guy, you want everyone to use best practices as you see them, but it > isn't Python's position to

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

On 22/05/2019 01.11, Glenn Linderman wrote: > On 5/21/2019 2:00 PM, Nathaniel Smith wrote: >> On Tue, May 21, 2019 at 10:43 AM Glenn Linderman >> wrote: >>> After maintaining my own version of http.server to fix or workaround some >>> of its deficiencies for some years, I discovered bottle.py.

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

On Tue, May 21, 2019 at 01:59:56PM -0400, Terry Reedy wrote: > On 5/21/2019 9:01 AM, Steven D'Aprano wrote: > ... > >Many Python users don't have the privilege of being able to install > >arbitrary, unvetted packages from PyPI. They get to use only packages > >from approved vendors, including the

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

On Wed, May 22, 2019 at 01:59:59PM +0900, Stephen J. Turnbull wrote: > This looks to me like an opening to a special class of supply chain > attacks. [...] > One thing we *could* do that would require moderate effort would be to > put them up on PyPI ourselves, and require that would-be

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

On Wed, May 22, 2019 at 10:07:31AM +0200, Christian Heimes wrote: > On 22/05/2019 06.20, Arfrever Frehtes Taifersar Arahesis wrote: > > It is possible to have a modern Linux desktop system with PAM not > > installed at all, and therefore not used. [...] Christian wrote: > Thanks for bringing

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

2019年5月22日(水) 18:57 Steven D'Aprano : > > > All deprecated modules will also undergo a feature freeze. No additional > > features should be added. Bug should still be fixed. > > I disagree with this. If people are requesting or contributing features > to a module, that's a good sign that it *is*

Re: [Python-Dev] PEP 594: update 1

On Tue, 21 May 2019 17:44:16 -0700 Brett Cannon wrote: > > > > So I should never have added those tests and then we wouldn't be talking > > about removing nntplib. > > > > Not necessarily. I suspect it still would have been listed, you would have > objected, and someone may have looked at the

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

On Tue, May 21, 2019 at 01:13:30PM -0400, Edwin Zimmerman wrote: [...] [-- Attachment #2: winmail.dat --] [-- Type: application/ms-tnef, Encoding: base64, Size: 8.4K --] Wow! I haven't see one of those for *years* -- I haven't noticed one for about 15 years, and I thought it was an obsolete

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

Let me be clear: I do not oppose the removal of modules where necessary, but I do not like this PEP as it stands. But full credit to Christian for graciously accepting feedback; I also acknowledge that if this PEP is accepted, we still have at least two releases to change our minds about

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

Neil Schemenauer writes: > Here is an alternative, straw man, proposal. Split the CPython repo > into two parts: > > - core Python: minimal possible stdlib > - everything else I take issue with the characterization of "straw man," it's a practical idea that turns out to be not so

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

On 22/05/2019 08.30, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 04:30, Antoine Pitrou > wrote: > > > NNTP is still quite used (often through GMane, but probably not only) so > I'd question the removal of nntplib. > > > I concur nntplib should

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

On 22/05/2019 06.20, Arfrever Frehtes Taifersar Arahesis wrote: > 2019-05-21 00:06 UTC+02:00, Christian Heimes wrote: >> On 20/05/2019 23.27, Antoine Pitrou wrote: >>> Removing the crypt module would remove support for system-standard >>> password files. I don't understand the rationale. >> >>

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

On 2019-05-21, Brett Cannon wrote: > On Tue., May 21, 2019, 13:07 Neil Schemenauer, > wrote: > > Here is an alternative, straw man, proposal. Split the CPython repo > > into two parts: > > > > - core Python: minimal possible stdlib > > - everything else > > How to this lighten the

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

On Tue, 21 May 2019 at 04:30, Antoine Pitrou wrote: > > NNTP is still quite used (often through GMane, but probably not only) so > I'd question the removal of nntplib. I concur nntplib should be left alone. There are possibly even less used network protocols such as telnet (tenetlib) which are

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

This vector exists today for all new stdlib modules: once added, any existing dependency could include that name to cater it to be imported on prior python versions. Rob On Wed, 22 May 2019, 17:03 Stephen J. Turnbull, < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Christian Heimes writes: > >

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

On Tue, May 21, 2019, at 14:17, Christian Heimes wrote: > thanks for bringing this topic up. Initially I considered http.server, > too. But as Guido put it, it's both used and useful for local testing > and quick hacks. I'm already facing opposition for modules that are > less controversial and

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

Christian Heimes writes: > It's all open source. It's up to the Python community to adopt > packages and provide them on PyPI. > > Python core will not maintain and distribute the packages. I'll > merely provide a repository with packages to help kick-starting the > process. This looks to

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

2019-05-21 00:06 UTC+02:00, Christian Heimes wrote: > On 20/05/2019 23.27, Antoine Pitrou wrote: >> Removing the crypt module would remove support for system-standard >> password files. I don't understand the rationale. > > Applications *must* not access system-standard password files directly.

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

On Tue., May 21, 2019, 13:07 Neil Schemenauer, wrote: > On 2019-05-21, Terry Reedy wrote: > > The problem with this argument, taken by itself, it that it would argue > for > > adding to the stdlib 100s or 1000s of modules or packages that would be > > useful to many more people than the modules

Re: [Python-Dev] PEP 594: update 1

I repeat my position: on an omnibus PEP like this, if there's this much debate about one module, it should be struck from the list. On Tue, May 21, 2019 at 5:46 PM Brett Cannon wrote: > > > On Tue., May 21, 2019, 11:29 Antoine Pitrou, wrote: > >> >> Le 21/05/2019 à 20:16, Brett Cannon a écrit

Re: [Python-Dev] PEP 544 and dunder methods

On Tue, May 21, 2019, 12:00 Guido van Rossum wrote: > My guess, without delving into the implementation, is that a Protocol is > *always* about the class, and that this is entirely a red herring. > I think you're right. It makes sense. I must have missed it somehow. FYI, some protocols (like

Re: [Python-Dev] PEP 594: update 1

On Tue., May 21, 2019, 11:29 Antoine Pitrou, wrote: > > Le 21/05/2019 à 20:16, Brett Cannon a écrit : > > > > > > On Tue., May 21, 2019, 09:10 Christian Heimes, > > wrote: > > > > On 21/05/2019 17.31, Antoine Pitrou wrote: > > > > > > As I said, if the

Re: [Python-Dev] PEP 587 "Python Initialization Configuration" version 4

Hi, Le lun. 20 mai 2019 à 21:36, Antoine Pitrou a écrit : > - Since PyInitError can be "ok", I'd rather call it "PyInitStatus". Oh, I like this name :-) By the way, I'm not comfortable with "PyInitError_Failed()" name since it's true if it's an error (failure) ... or "an exit". What do you

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

On 5/21/2019 2:00 PM, Nathaniel Smith wrote: On Tue, May 21, 2019 at 10:43 AM Glenn Linderman wrote: After maintaining my own version of http.server to fix or workaround some of its deficiencies for some years, I discovered bottle.py. It has far more capability, is far better documented, and

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

Le mar. 21 mai 2019 à 23:05, Nathaniel Smith a écrit : > If the tests don't work and the module is unmaintained, then maybe we > should disable the tests and put a prominent notice in the docs saying > that it's unmaintained and any use is at your own risk. It's not a > pleasant thing to do, but

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

On Tue, May 21, 2019 at 4:25 AM Victor Stinner wrote: > > Le mar. 21 mai 2019 à 13:18, André Malo a écrit : > > There's software in production using both. (It doesn't mean it's on pypi or > > even free software). > > > > What would be the maintenance burden of those modules anyway? (at least for

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

On Tue, May 21, 2019 at 10:43 AM Glenn Linderman wrote: > After maintaining my own version of http.server to fix or workaround some of > its deficiencies for some years, I discovered bottle.py. It has far more > capability, is far better documented, and is just as quick to deploy. While I >

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

On 5/21/2019 11:15 AM, Christian Heimes wrote: On 21/05/2019 18.29, 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

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

On 2019-05-21, Terry Reedy wrote: > The problem with this argument, taken by itself, it that it would argue for > adding to the stdlib 100s or 1000s of modules or packages that would be > useful to many more people than the modules proposed to be dropped. I don't think it does. We are not

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

On 21/05/2019 20.35, Guido van Rossum wrote: > On Tue, May 21, 2019 at 11:17 AM Christian Heimes > wrote: > > I'm already facing opposition for modules that are less controversial and > useful than http.server, too. > > > There's another argument here. This is

Re: [Python-Dev] PEP 544 and dunder methods

(I did see your post in the moderation queue and let it through -- however the mypy team, which would be most responsible for answering your question, has been busy fighting some fires.) I'm trying to understand what the PEP is saying and how you're interpreting, and I'm not getting very far. I

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

On Tue, May 21, 2019 at 11:17 AM Christian Heimes wrote: > I'm already facing opposition for modules that are less controversial and > useful than http.server, too. There's another argument here. This is an "omnibus" PEP, meaning it proposes many unrelated changes. In order to get a consensus

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 20.18, Giampaolo Rodola' wrote: > No, the statement is correct. I may have to explain this even further. > > The approach in pyftpdlib is the wrong and IMO deserves a CVE. The > crypt() + spwd() approach is flawed on multiple levels. For example it > bypasses account

Re: [Python-Dev] PEP 594: update 1

Le 21/05/2019 à 20:16, Brett Cannon a écrit : > > > On Tue., May 21, 2019, 09:10 Christian Heimes, > wrote: > > On 21/05/2019 17.31, Antoine Pitrou wrote: > > > > As I said, if the main annoyance with nntplib is the sporadic test > > failures, then

Re: [Python-Dev] PEP 594: update 1

On Tue, 21 May 2019 at 23:26, Christian Heimes wrote: > On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > > > > On Tue, 21 May 2019 at 21:13, Christian Heimes > wrote: > > > > crypt > > ~ > > > > The `crypt

Re: [Python-Dev] PEP 594: update 1

On Tue., May 21, 2019, 09:10 Christian Heimes, wrote: > On 21/05/2019 17.31, Antoine Pitrou wrote: > > > > As I said, if the main annoyance with nntplib is the sporadic test > > failures, then the relevant tests can be disabled on CI. > > > > NNTP itself is still used, even if less and less. > >

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

On 21/05/2019 16.46, Guido van Rossum wrote: > +1. Let's keep colorsys then. I let colorsys off the hock, https://github.com/python/peps/pull/1070 Thanks for your feedback, Walter and Petr! Christian ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 594: update 1

On 5/21/2019 10:12 AM, Christian Heimes wrote: --- PEP: 594 Title: Removing dead batteries from the standard library 'dead' seems controversial. 'nearly useless' should be less so. I think 'after 2.7 end-of-life' is worth

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

On Tue, 21 May 2019 13:59:56 -0400 Terry Reedy wrote: > On 5/21/2019 9:01 AM, Steven D'Aprano wrote: > ... > > Many Python users don't have the privilege of being able to install > > arbitrary, unvetted packages from PyPI. They get to use only packages > > from approved vendors, including the

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

On 21/05/2019 18.29, 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

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

On Tue., May 21, 2019, 04:25 Victor Stinner, wrote: > Le mar. 21 mai 2019 à 13:18, André Malo a écrit : > > There's software in production using both. (It doesn't mean it's on pypi > or > > even free software). > > > > What would be the maintenance burden of those modules anyway? (at least >

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

On 5/21/2019 9:01 AM, Steven D'Aprano wrote: ... Many Python users don't have the privilege of being able to install arbitrary, unvetted packages from PyPI. They get to use only packages from approved vendors, including the stdlib, what they write themselves, and nothing else. Please don't

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

``http.server`` is used in ``pydoc``: https://github.com/python/cpython/blob/ccb7ca728e09b307f9e9fd36ec40353137e68a3b/Lib/pydoc.py#L2236 On Tue, May 21, 2019 at 10:12:50AM -0700, Guido van Rossum wrote: > I still like http.server for quick temporary hacks where I want to be able > to point a

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

On 5/21/2019 10:12 AM, Guido van Rossum wrote: I still like http.server for quick temporary hacks where I want to be able to point a browser at some code I wrote 5 minutes ago and that I plan to discard in an hour. Usually it's running at localhost:8000. Remembering how to use Django, flask or

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] PEP 594: Removing dead batteries from the standard library

I still like http.server for quick temporary hacks where I want to be able to point a browser at some code I wrote 5 minutes ago and that I plan to discard in an hour. Usually it's running at localhost:8000. Remembering how to use Django, flask or Tornado seems overkill for that purpose. On Tue,

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 21:13, Christian Heimes > wrote: > > crypt > ~ > > The `crypt `_ module > implements > password hashing based on

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

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

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 21:13, Christian Heimes > wrote: > > crypt > ~ > > The `crypt `_ module > implements > password hashing based on

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 17.31, Antoine Pitrou wrote: > > As I said, if the main annoyance with nntplib is the sporadic test > failures, then the relevant tests can be disabled on CI. > > NNTP itself is still used, even if less and less. I don't like the idea to drop a third of the test cases for nntplib

Re: [Python-Dev] PEP 594: update 1

On Tue, 21 May 2019 at 21:13, Christian Heimes wrote: > crypt > ~ > > The `crypt `_ module > implements > password hashing based on ``crypt(3)`` function from ``libcrypt`` or > ``libxcrypt`` on Unix-like platform. The algorithms are mostly old,

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

Good point! On Tue, May 21, 2019 at 2:01 PM Paul Moore wrote: > On Tue, 21 May 2019 at 13:50, Steve Holden wrote: > > > > That seems entirely reasonable. I wonder if the larger community could > somehow form an organization (the Dead Parrot SIG?) that would at least > curate and monitor

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 17.35, Guido van Rossum wrote: > OK, sounds like nntplib can stay — this time.  > > On Tue, May 21, 2019 at 08:33 Antoine Pitrou > wrote: > > > As I said, if the main annoyance with nntplib is the sporadic test > failures, then the relevant

[Python-Dev] PEP 544 and dunder methods

[originally I sent this to typing-sig but I guess it got caught up in moderation.] In PEP 554 [1] it says: - Implement metaclass functionality to detect whether a class is a protocol or not. Add a class attribute _is_protocol = True if that is the case. Verify that a protocol class

<    1   2   3   4   5   6   7   8   9   10   >