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] Unrelated PRs linked to issues on bugs.python.org

One possible reason is when we wrote the wrong boo number in the PR, and then changed it to the correct one. Not sure if this was the case. The linking of PR number in boo is done in bpo. There was a similar issue: https://github.com/python/bugs.python.org/issues/25 On Wed, May 22, 2019, 12:21

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] Python in next Windows 10 update

On 21May2019 1621, MRAB wrote: Does it behave nicely with py.exe? This is still something of an open issue with the Store package for Python - py.exe doesn't look for the registry keys in a way that will find them (due to some very obscure compatibility quirks). The Store package does not

Re: [Python-Dev] Python in next Windows 10 update

On 2019-05-21 21:30, Steve Dower wrote: [snip] The associated blog post: https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/ Here are answers to a few questions that I assume will come up, at least from this audience that understands the issues better than most: *

Re: [Python-Dev] Python in next Windows 10 update

On 05/21/2019 01:30 PM, Steve Dower wrote: In the next Windows 10 update that starts rolling out today, we (Microsoft) have added "python.exe" and "python3.exe" commands that are installed on PATH *by default* and will open the Microsoft Store at the page where we (Python core team) publish

Re: [Python-Dev] Parser module in the stdlib

Le ven. 17 mai 2019 à 00:44, Nathaniel Smith a écrit : > Will the folks using forks be happy to switch to the stdlib version? > For example I can imagine that if black wants to process 3.7 input > code while running on 3.6, it might prefer a parser on PyPI even if > the stdlib version were

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

[Python-Dev] Unrelated PRs linked to issues on bugs.python.org

Hi, Since one or two weeks, I noticed that the bot which links GitHub pull requests to bugs.python.org issues started to link PRs to unrelated issues. Example: https://github.com/python/cpython/pull/13148 (merged 2 hours ago) just added to https://bugs.python.org/issue35363 (closed at the end of

Re: [Python-Dev] Python in next Windows 10 update

On 21/05/2019 22.30, Steve Dower wrote: > Hi all > > Just sharing this here because I think it's important for us to be aware of > it - I'm not trying to promote or sell anything here :) (Those who were at > the language summit have seen this already.) > > In the next Windows 10 update that

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] Python in next Windows 10 update

That’s great, Steve. Thanks for all of the work (by you and others) on this. -- Eric V. Smith True Blade Systems, Inc (301) 859-4544 > On May 21, 2019, at 4:30 PM, Steve Dower wrote: > > Hi all > > Just sharing this here because I think it's important for us to be aware of > it - I'm not

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

[Python-Dev] Python in next Windows 10 update

Hi all Just sharing this here because I think it's important for us to be aware of it - I'm not trying to promote or sell anything here :) (Those who were at the language summit have seen this already.) In the next Windows 10 update that starts rolling out today, we (Microsoft) have added

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] Parser module in the stdlib

On Mon., May 20, 2019, 16:00 Terry Reedy, wrote: > On 5/20/2019 11:55 AM, Guido van Rossum wrote: > > On Thu, May 16, 2019 at 3:57 PM Steve Dower > > wrote: > > > > [...] > > We still have the policy of not removing modules that exist in the > > Python

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

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

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 tests can be disabled on CI. > > NNTP itself is still used, even if less and less. > > Regards >

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

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. Regards Antoine. On Tue, 21 May 2019 16:12:42 +0200 Christian Heimes wrote: > Hi, > > I have updated the PEP with

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

Hi folks, After a couple of years hiatus, I finally got back to working on the reference implementation for PEP 558, my proposal to resolve some weird interactions between closures and trace functions in CPython by formally defining the expected semantics of the locals() builtin at function

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

+1. Let's keep colorsys then. On Tue, May 21, 2019 at 7:41 AM Petr Viktorin wrote: > On 5/21/19 12:06 PM, Christian Heimes wrote: > > On 21/05/2019 11.49, Nathaniel Smith wrote: > >> On Tue, May 21, 2019 at 2:40 AM Walter Dörwald > wrote: > >>> > >>> On 20 May 2019, at 22:15, Christian Heimes

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

Quick note on the pip discussion: if the likely remaining users of a module slated for deprecation are professionals maintaining some legacy code, pip is a fine solution. OTOH if the likely users are beginners, maybe pip is not great. In general I think it's fine to err on the side of caution --

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

> If this were my PEP, I'd call it "Removing unloved batteries from the > standard library". Or maybe, "Removing obsolete and (potentially) dangerous batteries from the standard library." I can certainly understand why either class of module would be removed. When bsddb185 was tossed out, I put

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

On 5/21/19 12:06 PM, Christian Heimes wrote: On 21/05/2019 11.49, Nathaniel Smith wrote: On Tue, May 21, 2019 at 2:40 AM Walter Dörwald wrote: On 20 May 2019, at 22:15, Christian Heimes wrote: Hi, here is the first version of my PEP 594 to deprecate and eventually remove modules from the

Re: [Python-Dev] deprecation of abstractstaticmethod and abstractclassmethod

On Thu, 16 May 2019 at 06:03, Steve Dower wrote: > > On 15May2019 1248, Nathaniel Smith wrote: > > I don't care about the deprecation either way. But can we fix the > > individual decorators so both orders work? Even if it requires a special > > case in the code, it seems worthwhile to remove a

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

On 21/05/2019 15.54, Victor Stinner wrote: > IMHO we should simply acknowledge this fact by mentioning it in the > PEP. We are aware that "pip install" is not always a valid option, but > we decided anyway to deprecate/remove modules because <...>. I like the idea. Could you create an issue or

[Python-Dev] PEP 594: update 1

Hi, I have updated the PEP with feedback from discussions. The highlights are: * Deprecate parser module * Keep fileinput module * Elaborate why crypt and spwd are dangerous and bad * Improve sections for cgitb, colorsys, nntplib, and smtpd modules * The colorsys, crypt, imghdr, sndhdr, and spwd

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

IMHO we should simply acknowledge this fact by mentioning it in the PEP. We are aware that "pip install" is not always a valid option, but we decided anyway to deprecate/remove modules because <...>. Victor Le mar. 21 mai 2019 à 15:29, Paul Moore a écrit : > > On Tue, 21 May 2019 at 14:03,

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

On Tue, 21 May 2019 at 14:03, Steven D'Aprano wrote: > I know that saying anything against pip and virtual environments is > heresy, but honestly, "just install it from PyPI" is not friendly to > beginners or those who just want something that works without a load of > extra complexity.

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

On 21/05/2019 15.01, Steven D'Aprano wrote: > Christian, I'm glad that you are privileged enough to find it simple and > straight forward to download and install, but for many Python users, it > is not so simple or straight forward. > > Many Python users don't have the privilege of being able

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

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 efforts to ensure their continued utility? I have no idea whether there is

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

The PEP title is prejudicial and inaccurate. These aren't "dead batteries", these are *working batteries* that you want to remove. If you want a fair and open debate on this, please change the title to something less prejudicial. If this were my PEP, I'd call it "Removing unloved batteries

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

On 5/21/19 8:37 AM, Christian Heimes wrote: On 21/05/2019 14.06, Anders Munch wrote: Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne af Christian Heimes * The removed modules will be available through PyPI. Will they? That's not the impression I got from the

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

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 efforts to ensure their continued utility? On Tue, May 21, 2019 at 1:40 PM Christian Heimes wrote: > On 21/05/2019 14.06, Anders

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

On 21/05/2019 14.06, Anders Munch wrote: > Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På > vegne af Christian Heimes >> * The removed modules will be available through PyPI. > > Will they? That's not the impression I got from the PEP. It's all open source. It's up

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

On Dienstag, 21. Mai 2019 13:46:34 CEST Christian Heimes wrote: > On 21/05/2019 13.08, André Malo wrote: > > On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote: > >> NNTP is still quite used (often through GMane, but probably not only) > >> so > >> I'd question the removal of nntplib. > >>

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

On 21/05/2019 13.50, Victor Stinner wrote: > Hi Christian, > > I dislike the PEP 594 title: "Removing dead batteries from the > standard library". A module is never "dead", there are always users, > even if there are less than 5 of them. I'm open for suggestions for a better title. > Extract of

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

On Dienstag, 21. Mai 2019 13:50:30 CEST Victor Stinner wrote: > Well, that makes sense. But so, what is the metric to decide if a > module is "widely used" or not? Yes. Exactly the question that pops up right now. I think, that's the main issue when including batteries in general (that's not

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

Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne af Christian Heimes > * The removed modules will be available through PyPI. Will they? That's not the impression I got from the PEP. regards, Anders ___ Python-Dev

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

Hi Christian, I dislike the PEP 594 title: "Removing dead batteries from the standard library". A module is never "dead", there are always users, even if there are less than 5 of them. Extract of the Rationale: "The modules are mostly historic data formats and APIs that have been superseded a

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

Am 21.05.19 um 13:39 schrieb André Malo: So what I hear is, this battery is definitely not dead, which is what the PEP is all about. it's just half charged (or discharged, depending on your POV), so to speak. Substitute: "none" should read pypi then? Every single module on this list will

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

On 21/05/2019 13.08, André Malo wrote: > On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote: >> NNTP is still quite used (often through GMane, but probably not only) so >> I'd question the removal of nntplib. >> >> cgitb used to be used by some Web frameworks in order to format >>

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

On Dienstag, 21. Mai 2019 13:24:34 CEST 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

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

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 > nntp, I guess it's not gonna change). The maintenance burden is

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

On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote: > NNTP is still quite used (often through GMane, but probably not only) so > I'd question the removal of nntplib. > > cgitb used to be used by some Web frameworks in order to format > exceptions. Perhaps one should check if that's still

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

On 21/05/2019 12.19, Giampaolo Rodola' wrote: > I find this one useful and would be a bit sad to see it go. FWIW I use it in > pyftpdlib and I suppose there are other apps out there relying on UNIX > password db for authentication. The fact that it’s a C module is also an > incentive to leave

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

On Tue, 21 May 2019 at 03:17, Christian Heimes wrote: spwd > > > The `spwd `_ module provides > direct access to Unix shadow password database using non-standard APIs. > In general it's a bad idea to use the spwd. The spwd circumvents system >

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

On 21/05/2019 11.49, Nathaniel Smith wrote: > On Tue, May 21, 2019 at 2:40 AM Walter Dörwald wrote: >> >> On 20 May 2019, at 22:15, Christian Heimes wrote: >> >>> Hi, >>> >>> here is the first version of my PEP 594 to deprecate and eventually >>> remove modules from the standard library. The PEP

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

It's covered in "Python in a Nutshell," Alex Martelli having been a promoter of its ability simplify many utility programs for a long time. Not that that's any guide as to what should be in 3.10, by which time we'll be four minor releases out of date anyway. On Tue, May 21, 2019 at 9:16 AM

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

On Tue, 21 May 2019 00:55:20 +0200 Christian Heimes wrote: > On 21/05/2019 00.13, Antoine Pitrou wrote: > > On Tue, 21 May 2019 00:06:35 +0200 > > Christian Heimes wrote: > >> On 20/05/2019 23.27, Antoine Pitrou wrote: > >>> NNTP is still quite used (often through GMane, but probably not

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

On 20 May 2019, at 22:15, Christian Heimes wrote: 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 Language Summit 2018, https://lwn.net/Articles/755229/. [...] colorsys

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

On 21/05/2019 02.16, Inada Naoki wrote: > I use fileinput for several times per year. > > fileinput is handy tool to write single script file to analyze log files. > > * In such tools, I don't need real argument parser. > * Some log files are compressed and some are not. > It seems argparse