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

Yeah, I was surprised to see fileinput on the list. It's indeed a handy little tool. On Mon, May 20, 2019 at 5:19 PM 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 re

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

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 doesn't support transparent decompression. * I don't want

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

On 21/05/2019 01.06, Terry Reedy wrote: > On 5/20/2019 6:06 PM, Christian Heimes 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. On

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

On 16/05/2019 23.12, Pablo Galindo Salgado wrote: > Hi everyone, > > TLDR > = > > I propose to remove the current parser module and expose pgen2 as a standard > library module. I like to add this to PEP 594, see https://github.com/python/peps/pull/1063 Terry, thanks for connecting my PEP w

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

On 5/20/2019 6:06 PM, Christian Heimes 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. On any sanely and securely configured systems, applicatio

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

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 2 standard library. But 3.9 won't be covered by that :) I didn't even re

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

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 only) so >>> I'd question the removal of nntplib. >> >> Is NNTP support impo

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

On Tue, 21 May 2019 00:41:19 +0200 Simon Cross wrote: > Woot. +100 on this PEP. > > > If the stdlib didn't have NNTP support, obviously nobody would suggest > > adding it nowadays. > > Perhaps this is a good reason to keep nntplib in the deprecation list? No, because the same applies to getop

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

Woot. +100 on this PEP. > If the stdlib didn't have NNTP support, obviously nobody would suggest > adding it nowadays. Perhaps this is a good reason to keep nntplib in the deprecation list? Another question is "are there any places using nntplib where `pip install nntplib`" is not an reasonable o

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

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 only) so > > I'd question the removal of nntplib. > > Is NNTP support important enough to keep the module in the standard l

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

What replacements are available for NNTP? All I could find was pynntp, which had a single release 6 years ago. https://github.com/greenbender/pynntp //Jeff On 5/20/19 2:27 PM, Antoine Pitrou wrote: NNTP is still quite used (often through GMane, but probably not only) so I'd question the remov

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

On 20/05/2019 23.27, Antoine Pitrou wrote: > NNTP is still quite used (often through GMane, but probably not only) so > I'd question the removal of nntplib. Is NNTP support important enough to keep the module in the standard library? > cgitb used to be used by some Web frameworks in order to form

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

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 the case. If the wave module depends on the audioop module, and if

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

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 sockets

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

socketserver.py is also questionable On Mon, May 20, 2019 at 11:15 PM 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,

[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 Language Summit 2018, https://lwn.net/Articles/755229/. The PEP can be confirmed in two stages. I'm not planning any code chang

Re: [Python-Dev] bpo-36919: Exception from 'compile' reports a newline char not present in input

I answered (B) in the tracker. On Mon, May 20, 2019 at 12:32 PM Pavel Koneski wrote: > Hi, > > The following issue arose when implementing IronPython 3. Normally the > behavior of CPython is authoritative, but in this case I started having > doubts. > > Since Python 3.2, input in 'exec' mode of

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

Hi, - Since PyInitError can be "ok", I'd rather call it "PyInitStatus". - The PyConfig example sets "module_search_paths" but not "module_search_paths_set". Is it an error? - "PyConfig_InitPythonConfig" vs "PyConfig_InitIsolatedConfig": why not "PyConfig_InitConfig" and "PyConfig_InitIsol

[Python-Dev] bpo-36919: Exception from 'compile' reports a newline char not present in input

Hi, The following issue arose when implementing IronPython 3. Normally the behavior of CPython is authoritative, but in this case I started having doubts. Since Python 3.2, input in 'exec' mode of 'compile' does not have to end in a newline anymore. However, it creates a surprising behavior when

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

On Mon, May 20, 2019 at 11:29 AM Steven D'Aprano wrote: > On Mon, May 20, 2019 at 08:55:59AM -0700, Guido van Rossum wrote: > > > I am interested in switching CPython's parsing strategy to something else > > (what exactly remains to be seen) > > Are you re-thinking the restriction to LL(1) gramma

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

On Mon, May 20, 2019 at 08:55:59AM -0700, Guido van Rossum wrote: > I am interested in switching CPython's parsing strategy to something else > (what exactly remains to be seen) Are you re-thinking the restriction to LL(1) grammars? -- Steven ___ Pyt

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

> Actually, I think the `ast` module doesn't work very well for formatters, because it loses comments. (Retaining comments and all details of whitespace is the specific use case for which I created pgen2.) Some uses I have seen include using it to check that the code before and after the formattin

Re: [Python-Dev] ast changes for "debug" f-strings

On 5/20/2019 10:32 AM, Batuhan Taskaya wrote: > This strictly speaking isn't necessary. I could have added another Constant node for "x=" and left FormattedValue alone. I didn't for three reasons: it was expedient; it didn't require a lot of surgery to f-string parsing, which the extra Constant

Re: [Python-Dev] ast changes for "debug" f-strings

20.05.19 16:25, Eric V. Smith пише: I added an optional "expr_text" field to the FormattedValue node, which represents the text of the expression in a "debug" f-string expression. So in f'{x=}', expr_text would be "x=". This strictly speaking isn't necessary. I could have added another Consta

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

On Thu, May 16, 2019 at 3:51 PM Pablo Galindo Salgado wrote: > [Nathaniel Smith] > >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 > >

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

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 2 standard library. But 3.9 won't be covered by that :) > I didn't even remember that. Where's that written down? And by the time 3.8 .0(final) comes out, 2.7

Re: [Python-Dev] Plan to accept PEP 544, PEP 586, PEP 589, PEP 591 -- last call for discussion

FYI, copy of Guido's message: --- I'm planning to accept the following PEPs related to the type system later this week: PEP 544: Protocols PEP 586: Literal Types PEP 591: Final qualifier and @final decorator PEP 589: TypedDict All of these have been proposed for and discussed before. All of thes

Re: [Python-Dev] ast changes for "debug" f-strings

> This strictly speaking isn't necessary. I could have added another Constant node for "x=" and left FormattedValue alone. I didn't for three reasons: it was expedient; it didn't require a lot of surgery to f-string parsing, which the extra Constant node would require; and it allowed the Python/ast

[Python-Dev] Plan to accept PEP 544, PEP 586, PEP 589, PEP 591 -- last call for discussion

Please send all discussions about these PEPs to the typing-sig mailing list, so we have the archives all in one place. Read the full message here: https://mail.python.org/archives/list/typing-...@python.org/thread/GCI2TF43SESP2XVSETWOW33SRRWQTHM4/ -- --Guido van Rossum (python.org/~guido) *Prono

[Python-Dev] ast changes for "debug" f-strings

I added an optional "expr_text" field to the FormattedValue node, which represents the text of the expression in a "debug" f-string expression. So in f'{x=}', expr_text would be "x=". This strictly speaking isn't necessary. I could have added another Constant node for "x=" and left FormattedVa

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

Hi, I expected the version 3 of my PEP to be complete, but Gregory Szorc and Steve Dower spotted a few more issues ;-) The main change of the version 4 is the introduction of "Python Configuration" and "Isolated Configuration" default configuration which are well better defined. The new "Isolate

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

Hi Gregory, IMHO your remarks are not directly related to the PEP 587 and can be addressed in parallel. > It sounds like PyOxidizer and Hermetic Python are on the same page and > we're working towards a more official solution. But I want to make sure > by explicitly stating what PyOxidizer is doi

Re: [Python-Dev] Feature request: Change a Dependency Package Version During Package Initiation

I suspect this discussion would be better moved to python-ideas, since it seems clear there needs to be some work on determining the exact requirements On Sat, May 18, 2019 at 4:03 PM Dan Ryan wrote: > It probably makes the most sense to formally outline all of the behavioral > changes, expecta