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

On 6/4/2019 8:21 PM, Victor Stinner wrote: So what is happening for this PEP since Python 3.8 beta1 has been released? Is it too late for Python 3.8 or not? The only action proposed for 3.8 was soft deprecation in the docs, which I presume can be done later in the beta process. It seems lik

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

So what is happening for this PEP since Python 3.8 beta1 has been released? Is it too late for Python 3.8 or not? It seems like most people are confused by the intent of the PEP. IMHO it would be better to rewrite "Remove packages from the stdlib" as "Move some stdlib modules to PyPI". But that wo

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

On Sat, May 25, 2019 at 8:00 PM Daniel Moisset wrote: > 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 >

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 exam

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 majo

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 possib

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 coll

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: 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 fee

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 and

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

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 by

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: 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 dep

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: 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: 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 the

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 li

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 nntp

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

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 t

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

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 restri

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: 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 addin

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 ``crypt(3)

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 ``crypt(3)

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, of

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 test

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 fee

[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