Mailman 3 Deprecating the formatter module - Python-Dev

Deprecating the formatter module

older
Re: [Python-Dev] cpython: Cleanup...

Brett Cannon

13 Aug 2013 13 Aug '13

12:52 a.m.

At the PyCon CA sprint someone discovered the formatter module had somewhat low code coverage. We discovered this is because it's tested by test_sundry, i.e. it's tested by importing it and that's it. We then realized that it isn't really used by anyone (pydoc uses it but it should have been using textwrap). Looking at the history of the module it has just been a magnet for cleanup revisions and not actual usage or development since Guido added it back in 1995. I have created http://bugs.python.org/issue18716 to deprecate the formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

Attachments:

attachment.htm (text/html — 814 bytes)

Show replies by date

Paul Moore

13 Aug 13 Aug

1:41 a.m.

On 12 August 2013 20:22, Brett Cannon wrote:

...

At the PyCon CA sprint someone discovered the formatter module had somewhat low code coverage. We discovered this is because it's tested by test_sundry, i.e. it's tested by importing it and that's it.

We then realized that it isn't really used by anyone (pydoc uses it but it should have been using textwrap). Looking at the history of the module it has just been a magnet for cleanup revisions and not actual usage or development since Guido added it back in 1995.

I have created http://bugs.python.org/issue18716 to deprecate the formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

I can see no reason to object. But having looked at the module for the first time on the basis of this email, I have to say that if I'd stumbled across it by chance, my reaction would have been that it was another one of Python's "hidden gems" that I'd never been aware of. I would then, of course, have filed it for future reference "should I need it", and never actually used it. So I'm OK for it to go, but a little sad nevertheless :-) Paul

Larry Hastings

2:36 a.m.

On 08/12/2013 04:11 PM, Paul Moore wrote:

...

[...] if I'd stumbled across it by chance, my reaction would have been that it was another one of Python's "hidden gems" that I'd never been aware of.

Hidden "gem"? No. Hidden "paste diamond", maybe. YAGNI, //arry/

Ryan

2:31 a.m.

I never realized it existed till now. Considering the usually erratic projects I like do, I can see that coming in use in several in which I had to do odd workarounds. Keep it, but put better documentation. It's needed. Brett Cannon wrote:

...

At the PyCon CA sprint someone discovered the formatter module had somewhat low code coverage. We discovered this is because it's tested by test_sundry, i.e. it's tested by importing it and that's it.

We then realized that it isn't really used by anyone (pydoc uses it but it should have been using textwrap). Looking at the history of the module it has just been a magnet for cleanup revisions and not actual usage or development since Guido added it back in 1995.

I have created http://bugs.python.org/issue18716 to deprecate the formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

------------------------------------------------------------------------

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Phil Elson

2:47 p.m.

On 12 August 2013 22:01, Ryan wrote:

...

Keep it, but put better documentation. It's needed.

There are many a useful package outside of the standard library. If this is genuinely useful in some specialist use cases then I'm sure the code will find its way to a github repo and be maintained as a standalone package in itself. Who knows, being outside of the stdlib might breathe a new lease of life into the concept if the release cycles are not bound to Python releases. Personally, I'd say delete it, unless there is a good reason not to.

Eli Bendersky

2:52 a.m.

On Mon, Aug 12, 2013 at 12:22 PM, Brett Cannon wrote:

...

At the PyCon CA sprint someone discovered the formatter module had somewhat low code coverage. We discovered this is because it's tested by test_sundry, i.e. it's tested by importing it and that's it.

We then realized that it isn't really used by anyone (pydoc uses it but it should have been using textwrap). Looking at the history of the module it has just been a magnet for cleanup revisions and not actual usage or development since Guido added it back in 1995.

I have created http://bugs.python.org/issue18716 to deprecate the formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

I wish we had a way to collect real-world usage on such things. I tried a couple of code search engines, but this one is difficult to unravel because many Python packages have their own formatter module (for example Django, pygments) that probably does something different. Eli

Antoine Pitrou

3:19 a.m.

On Mon, 12 Aug 2013 14:22:01 -0700 Eli Bendersky wrote:

...

On Mon, Aug 12, 2013 at 12:22 PM, Brett Cannon wrote:

...
At the PyCon CA sprint someone discovered the formatter module had somewhat low code coverage. We discovered this is because it's tested by test_sundry, i.e. it's tested by importing it and that's it.

We then realized that it isn't really used by anyone (pydoc uses it but it should have been using textwrap). Looking at the history of the module it has just been a magnet for cleanup revisions and not actual usage or development since Guido added it back in 1995.

I have created http://bugs.python.org/issue18716 to deprecate the formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

I wish we had a way to collect real-world usage on such things. I tried a couple of code search engines, but this one is difficult to unravel because many Python packages have their own formatter module (for example Django, pygments) that probably does something different.

"Ohloh code search" shows a couple matches for AbstractFormatter in Python projects: http://code.ohloh.net/search?s=%22AbstractFormatter%22&pp=0&fl=Python&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true

Serhiy Storchaka

4:04 p.m.

12.08.13 22:22, Brett Cannon написав(ла):

...

I have created http://bugs.python.org/issue18716 to deprecate the formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

The formatter module doesn't look such buggy as the audioop module. If the formatter module was not removed in Python 3.0 I don't see why it can't wait to 4.0.

Brett Cannon

7:06 p.m.

On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka wrote:

...

12.08.13 22:22, Brett Cannon написав(ла):

I have created http://bugs.python.org/**issue18716 http://bugs.python.org/issue18716to deprecate the

...
formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

The formatter module doesn't look such buggy as the audioop module. If the formatter module was not removed in Python 3.0 I don't see why it can't wait to 4.0.

It doesn't help that at PyCon CA we couldn't find a single person who had heard of the module (which included people like Alex Gaynor and Larry Hastings). I'm definitely deprecating it, but we can discuss postponing deletion.

Nick Coghlan

8:05 p.m.

On 13 Aug 2013 09:39, "Brett Cannon" wrote:

...

On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka

...

...
12.08.13 22:22, Brett Cannon написав(ла):

...
I have created http://bugs.python.org/issue18716 to deprecate the formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

The formatter module doesn't look such buggy as the audioop module. If

wrote: the formatter module was not removed in Python 3.0 I don't see why it can't wait to 4.0.

...

It doesn't help that at PyCon CA we couldn't find a single person who had

heard of the module (which included people like Alex Gaynor and Larry Hastings).

...

I'm definitely deprecating it, but we can discuss postponing deletion.

Unless something is a serious bug magnet or is causing us maintenance hassles, we shouldn't remove it. Neither applies here, so an indefinite PendingDeprecation makes the most sense to me. Cheers, Nick.

...

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

...

Steven D'Aprano

14 Aug 14 Aug

7:52 a.m.

On 13/08/13 23:36, Brett Cannon wrote:

...

On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka wrote:

...
12.08.13 22:22, Brett Cannon написав(ла):

I have created http://bugs.python.org/**issue18716 http://bugs.python.org/issue18716to deprecate the

...
formatter module for removal in Python 3.6 unless someone convinces me otherwise that deprecation and removal is the wrong move.

The formatter module doesn't look such buggy as the audioop module. If the formatter module was not removed in Python 3.0 I don't see why it can't wait to 4.0.

It doesn't help that at PyCon CA we couldn't find a single person who had heard of the module (which included people like Alex Gaynor and Larry Hastings).

You know, there may be one or two Python programmers who didn't go to PyCon CA... :-) I knew of formatter before this thread. I've looked at it for use in my own code, but the lack of useful documentation or clear examples put me off, so I put it in the pile of "things to investigate later", but it is definitely a module that interests me. The documentation for 2.7 claims that it is used by HTMLParser, but that doesn't appear to be true. The claim is removed from the 3.3 documentation. Over on Python-Ideas mailing list, there are periodic frenzies of requests to delete all sorts of things, e.g. a recent thread debating deleting various string methods in favour of using {} string formatting. My answer there is the same as my answer here: unless the formatter module is actively harmful, then deprecation risks causing more pain than benefit. All those thousands of coders who don't use formatter? The benefit to them of deprecating it is next to zero. That one guy in Uberwald you've never heard of who does use it? It's going to cause him a lot of pain. -- Steven

Brett Cannon

8:38 p.m.

On Tue, Aug 13, 2013 at 10:22 PM, Steven D'Aprano wrote:

...

On 13/08/13 23:36, Brett Cannon wrote:

...
On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka
...
wrote:

12.08.13 22:22, Brett Cannon написав(ла):

...
I have created http://bugs.python.org/****issue18716 http://bugs.python.org/**issue18716 <http://bugs.python.**org/issue18716 http://bugs.python.org/issue18716>to deprecate the

formatter module for removal in Python 3.6 unless someone convinces me

...
otherwise that deprecation and removal is the wrong move.

The formatter module doesn't look such buggy as the audioop module. If the formatter module was not removed in Python 3.0 I don't see why it can't wait to 4.0.

It doesn't help that at PyCon CA we couldn't find a single person who had heard of the module (which included people like Alex Gaynor and Larry Hastings).

You know, there may be one or two Python programmers who didn't go to PyCon CA... :-)

Sure, but you would assume at least *one* person would have known of the module in a room of sprinters.

...

I knew of formatter before this thread. I've looked at it for use in my own code, but the lack of useful documentation or clear examples put me off, so I put it in the pile of "things to investigate later", but it is definitely a module that interests me.

Sure, but not to the extent to try and update the documentation, provide examples, etc. And totally lacking tests doesn't help with the argument there is interest in it either.

...

The documentation for 2.7 claims that it is used by HTMLParser, but that doesn't appear to be true. The claim is removed from the 3.3 documentation.

Over on Python-Ideas mailing list, there are periodic frenzies of requests to delete all sorts of things, e.g. a recent thread debating deleting various string methods in favour of using {} string formatting. My answer there is the same as my answer here: unless the formatter module is actively harmful, then deprecation risks causing more pain than benefit. All those thousands of coders who don't use formatter? The benefit to them of deprecating it is next to zero. That one guy in Uberwald you've never heard of who does use it? It's going to cause him a lot of pain.

That's fine, but this is also about me and every other core developer who stands behind every module in the stdlib as being as bug-free as possible and generally useful to warrant people learning about them. I'm saying I don't want to maintain it and have to clean up it's code every time there is a stdlib-wide cleanup or if there is ever a bug. Every bug takes time and effort away -- no matter how infrequently the module has them -- from other modules which people could be focusing their time on which have a greater impact on the wider community. You can argue that some core dev might care enough to maintain it, but unless someone lists themselves on http://docs.python.org/devguide/experts.html for a module then the burden of maintenance falls on all of us. There is also the issue of semantic overload in terms of simply trying to keep straight what is in the stdlib. It also means book authors need to decide whether to care about this module or not and use it in examples. Teachers need to be aware of the module to answer questions, etc. We take adding a module to the stdlib very seriously for all of these reasons and yet people seem to forget that the exact same reasons apply to modules already in the stdlib, whether they would be added today or not (and in this instance I would argue not). There is a balance to keeping the load of work for core devs at a level that is tenable to the level of quality we expect from ourselves which means making sure we don't let cruft build up in the stdlib and overwhelm us.

Antoine Pitrou

8:56 p.m.

Le Wed, 14 Aug 2013 11:08:29 -0400, Brett Cannon a écrit :

...

...
You know, there may be one or two Python programmers who didn't go to PyCon CA... :-)

Sure, but you would assume at least *one* person would have known of the module in a room of sprinters.

Not necessarily. There are specialized modules which may be of use to only a certain category of people, and unknown to others.

...

...
Over on Python-Ideas mailing list, there are periodic frenzies of requests to delete all sorts of things, e.g. a recent thread debating deleting various string methods in favour of using {} string formatting. My answer there is the same as my answer here: unless the formatter module is actively harmful, then deprecation risks causing more pain than benefit. All those thousands of coders who don't use formatter? The benefit to them of deprecating it is next to zero. That one guy in Uberwald you've never heard of who does use it? It's going to cause him a lot of pain.

That's fine, but this is also about me and every other core developer who stands behind every module in the stdlib as being as bug-free as possible and generally useful to warrant people learning about them. I'm saying I don't want to maintain it and have to clean up it's code every time there is a stdlib-wide cleanup or if there is ever a bug.

Not all of us have to maintain it :-) I'm not gonna maintain it either, but that doesn't mean someone else won't step up. Regards Antoine.

Nick Coghlan

9:17 p.m.

On 14 August 2013 11:08, Brett Cannon wrote:

...

We take adding a module to the stdlib very seriously for all of these reasons and yet people seem to forget that the exact same reasons apply to modules already in the stdlib, whether they would be added today or not (and in this instance I would argue not). There is a balance to keeping the load of work for core devs at a level that is tenable to the level of quality we expect from ourselves which means making sure we don't let cruft build up in the stdlib and overwhelm us.

I've already suggested a solution to that at the language summit [1]: we create a "Legacy Modules" section in the docs index and dump all the modules that are in the "These are only in the standard library because they were added before PyPI existed, aren't really actively maintained, but we can't remove them due to backwards compatibility concerns" category there. Clear indication of their status for authors, educators, future users and us, with no risk of breaking currently working code. Cheers, Nick. [1] http://python-notes.curiousefficiency.org/en/latest/conferences/pyconus2013/... -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Brett Cannon

9:25 p.m.

On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan wrote:

...

On 14 August 2013 11:08, Brett Cannon wrote:

...
We take adding a module to the stdlib very seriously for all of these reasons and yet people seem to forget that the exact same reasons apply to modules already in the stdlib, whether they would be added today or not (and in this instance I would argue not). There is a balance to keeping the load of work for core devs at a level that is tenable to the level of quality we expect from ourselves which means making sure we don't let cruft build up in the stdlib and overwhelm us.

I've already suggested a solution to that at the language summit [1]: we create a "Legacy Modules" section in the docs index and dump all the modules that are in the "These are only in the standard library because they were added before PyPI existed, aren't really actively maintained, but we can't remove them due to backwards compatibility concerns" category there.

Clear indication of their status for authors, educators, future users and us, with no risk of breaking currently working code.

I view a deprecation as the same thing. If we leave the module in until Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.

Nick Coghlan

9:39 p.m.

On 14 August 2013 11:55, Brett Cannon wrote:

...

On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan wrote:

...
On 14 August 2013 11:08, Brett Cannon wrote:

...
We take adding a module to the stdlib very seriously for all of these reasons and yet people seem to forget that the exact same reasons apply to modules already in the stdlib, whether they would be added today or not (and in this instance I would argue not). There is a balance to keeping the load of work for core devs at a level that is tenable to the level of quality we expect from ourselves which means making sure we don't let cruft build up in the stdlib and overwhelm us.

I've already suggested a solution to that at the language summit [1]: we create a "Legacy Modules" section in the docs index and dump all the modules that are in the "These are only in the standard library because they were added before PyPI existed, aren't really actively maintained, but we can't remove them due to backwards compatibility concerns" category there.

Clear indication of their status for authors, educators, future users and us, with no risk of breaking currently working code.

I view a deprecation as the same thing. If we leave the module in until Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.

No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Brett Cannon

9:42 p.m.

On Wed, Aug 14, 2013 at 12:09 PM, Nick Coghlan wrote:

...

On 14 August 2013 11:55, Brett Cannon wrote:

...
On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan wrote:

...
On 14 August 2013 11:08, Brett Cannon wrote:

...
We take adding a module to the stdlib very seriously for all of these reasons and yet people seem to forget that the exact same reasons

apply

...
...
to modules already in the stdlib, whether they would be added today or not (and in this instance I would argue not). There is a balance to keeping the load of work for core devs at a level that is tenable to the level of quality we expect from ourselves which means making sure we don't let cruft build up in the stdlib and overwhelm us.

I've already suggested a solution to that at the language summit [1]: we create a "Legacy Modules" section in the docs index and dump all the modules that are in the "These are only in the standard library because they were added before PyPI existed, aren't really actively maintained, but we can't remove them due to backwards compatibility concerns" category there.

Clear indication of their status for authors, educators, future users and us, with no risk of breaking currently working code.

I view a deprecation as the same thing. If we leave the module in until Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.

No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both.

That I'm fine with, your wording just suggested to me you were only thinking of the doc change.

Eli Bendersky

9:47 p.m.

On Wed, Aug 14, 2013 at 9:09 AM, Nick Coghlan wrote:

...

On 14 August 2013 11:55, Brett Cannon wrote:

...
On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan wrote:

...
On 14 August 2013 11:08, Brett Cannon wrote:

...
We take adding a module to the stdlib very seriously for all of these reasons and yet people seem to forget that the exact same reasons

apply

...
...
to modules already in the stdlib, whether they would be added today or not (and in this instance I would argue not). There is a balance to keeping the load of work for core devs at a level that is tenable to the level of quality we expect from ourselves which means making sure we don't let cruft build up in the stdlib and overwhelm us.

I've already suggested a solution to that at the language summit [1]: we create a "Legacy Modules" section in the docs index and dump all the modules that are in the "These are only in the standard library because they were added before PyPI existed, aren't really actively maintained, but we can't remove them due to backwards compatibility concerns" category there.

Clear indication of their status for authors, educators, future users and us, with no risk of breaking currently working code.

I view a deprecation as the same thing. If we leave the module in until Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.

No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both.

+1 for both and for leaving the module in until "Python 4". Nick, perhaps we can have this "legacy-zation" process for modules documented somewhere? Devguide? mini-PEP? Eli

MRAB

9:53 p.m.

On 14/08/2013 17:17, Eli Bendersky wrote:

...

On Wed, Aug 14, 2013 at 9:09 AM, Nick Coghlan mailto:ncoghlan@gmail.com> wrote:

On 14 August 2013 11:55, Brett Cannon mailto:brett@python.org> wrote: > On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan mailto:ncoghlan@gmail.com> wrote: >> >> On 14 August 2013 11:08, Brett Cannon mailto:brett@python.org> wrote: >> > We take adding a module to the stdlib very seriously for all of these >> > reasons and yet people seem to forget that the exact same reasons apply >> > to >> > modules already in the stdlib, whether they would be added today or not >> > (and >> > in this instance I would argue not). There is a balance to keeping the >> > load >> > of work for core devs at a level that is tenable to the level of quality >> > we >> > expect from ourselves which means making sure we don't let cruft build >> > up in >> > the stdlib and overwhelm us. >> >> I've already suggested a solution to that at the language summit [1]: >> we create a "Legacy Modules" section in the docs index and dump all >> the modules that are in the "These are only in the standard library >> because they were added before PyPI existed, aren't really actively >> maintained, but we can't remove them due to backwards compatibility >> concerns" category there. >> >> Clear indication of their status for authors, educators, future users >> and us, with no risk of breaking currently working code. > > > I view a deprecation as the same thing. If we leave the module in until > Python 4 then I can live with that, but simply moving documentation around > is not enough to communicate to those who didn't read the release notes to > know modules they rely on are now essentially orphaned.

No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both.

+1 for both and for leaving the module in until "Python 4".

Nick, perhaps we can have this "legacy-zation" process for modules documented somewhere? Devguide? mini-PEP?

What about also for certain features of modules, such as re's LOCALE flag?

Nick Coghlan

11:12 p.m.

On 14 August 2013 12:17, Eli Bendersky wrote:

...

On Wed, Aug 14, 2013 at 9:09 AM, Nick Coghlan wrote:

...
On 14 August 2013 11:55, Brett Cannon wrote:

...
I view a deprecation as the same thing. If we leave the module in until Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.

No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both.

+1 for both and for leaving the module in until "Python 4".

Nick, perhaps we can have this "legacy-zation" process for modules documented somewhere? Devguide? mini-PEP?

That would be PEP 4 :) PEPs 5 and 6 could do with some TLC, too :P Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Chris Angelico

11:20 p.m.

On Wed, Aug 14, 2013 at 6:42 PM, Nick Coghlan wrote:

...

That would be PEP 4 :)

What's the normal way to update a PEP? """"... proposals for deprecating modules MUST be made by providing a change to the text of this PEP, which SHOULD be a patch posted to SourceForge...""" Would that now be more accurately done as a Mercurial patch, or a tracker issue? ChrisA

Brett Cannon

11:45 p.m.

On Wed, Aug 14, 2013 at 1:50 PM, Chris Angelico wrote:

...

On Wed, Aug 14, 2013 at 6:42 PM, Nick Coghlan wrote:

...
That would be PEP 4 :)

What's the normal way to update a PEP?

""""... proposals for deprecating modules MUST be made by providing a change to the text of this PEP, which SHOULD be a patch posted to SourceForge..."""

Would that now be more accurately done as a Mercurial patch, or a tracker issue?

Email here with proposed changes and/or email to PEP editors (skip python-dev if it's a simple typo fix).

Terry Reedy

15 Aug 15 Aug

12:07 a.m.

On 8/14/2013 12:09 PM, Nick Coghlan wrote:

...

On 14 August 2013 11:55, Brett Cannon wrote:

...

...
I view a deprecation as the same thing. If we leave the module in until Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.

No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both.

At least a couple of releases before deletion, we should put a 'legacy' package up on pypi. Then the deprecation message could say to use that as an alternative. -- Terry Jan Reedy

Eli Bendersky

12:15 a.m.

On Wed, Aug 14, 2013 at 11:37 AM, Terry Reedy wrote:

...

On 8/14/2013 12:09 PM, Nick Coghlan wrote:

...
On 14 August 2013 11:55, Brett Cannon wrote:

I view a deprecation as the same thing. If we leave the module in until

...
...
Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.

No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both.

At least a couple of releases before deletion, we should put a 'legacy' package up on pypi. Then the deprecation message could say to use that as an alternative.

To reiterate a point that was raised previously -- IMHO it would be a mistake to actually delete this (or other) modules before "Python 4". There's been enough breakage in Python 3 already. Some projects may only switch to Python 3.x when x is 4 or 5 or 9. Let's not make it even harder! I suggest we revisit this issue when the module in question becomes an actual maintenance burden. For the time being, if we feel bad this module isn't well documented/tested/understood, ISTM that moving it to "deprecated" status and to a "legacy/obsolete" section of the library documentation should help us handle those feelings of guilt. Eli

Steven D'Aprano

6:58 a.m.

On 15/08/13 01:08, Brett Cannon wrote:

...

On Tue, Aug 13, 2013 at 10:22 PM, Steven D'Aprano wrote:

...
On 13/08/13 23:36, Brett Cannon wrote:

...
On Tue, Aug 13, 2013 at 6:34 AM, Serhiy Storchaka
...
wrote:

12.08.13 22:22, Brett Cannon написав(ла):

...
I have created http://bugs.python.org/****issue18716 http://bugs.python.org/**issue18716 <http://bugs.python.**org/issue18716 http://bugs.python.org/issue18716>to deprecate the

formatter module for removal in Python 3.6 unless someone convinces me

...
otherwise that deprecation and removal is the wrong move.

[...] There is a balance to keeping the load of work for core devs at a level that is tenable to the level of quality we expect from ourselves which means making sure we don't let cruft build up in the stdlib and overwhelm us.

These are all very good arguments, for both sides, and it is a balance between code churn and bit rot, but on balance I'm going to come down firmly in favour of Nick's earlier recommendation: PendingDeprecation (and/or a move to a "Legacy" section in the docs). In a couple more releases there may be concrete plans for an eventual Python 4, at which time we can discuss whether to delay deprecation until Python 4 or drop it sooner. And in the meantime, perhaps somebody will decide to give the module some love and attention. I'm not able to give a commitment to do so right now, but it is a module that interests me so maybe it will be me, he says optimistically. -- Steven

Antoine Pitrou

2:38 p.m.

On Thu, 15 Aug 2013 11:28:52 +1000 Steven D'Aprano wrote:

...

These are all very good arguments, for both sides, and it is a balance between code churn and bit rot, but on balance I'm going to come down firmly in favour of Nick's earlier recommendation: PendingDeprecation (and/or a move to a "Legacy" section in the docs). In a couple more releases there may be concrete plans for an eventual Python 4, at which time we can discuss whether to delay deprecation until Python 4 or drop it sooner.

We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now. Regards Antoine.

Victor Stinner

2:46 p.m.

2013/8/15 Antoine Pitrou :

...

We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable). I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions? Victor

Antoine Pitrou

2:52 p.m.

On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...

2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change. Regards Antoine.

Brett Cannon

5:53 p.m.

On Thu, Aug 15, 2013 at 5:22 AM, Antoine Pitrou wrote:

...

On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

Getting a little ahead of ourselves with defining what exactly Python 4 will be, but I have been thinking that if we take a "deprecated modules sit in Python 3 bitrotting until Python 4 for backwards-compatibility reasons" then I'm fine with that as that gives a long period of adjustment to the module going away. I just don't want any deprecated module to sit there forever.

R. David Murray

5:59 p.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...

On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally? If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally. (I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?) --David

Antoine Pitrou

6:06 p.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

On Thu, 15 Aug 2013 08:29:35 -0400 "R. David Murray" wrote:

...

On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...
On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't.

Which is why we shouldn't silence deprecation warnings. Regards Antoine.

Brett Cannon

6:10 p.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou wrote:

...

On Thu, 15 Aug 2013 08:29:35 -0400 "R. David Murray" wrote:

...
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...
On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't.

Which is why we shouldn't silence deprecation warnings.

What we should probably do is have unittest turn deprecations on by default when running your tests but leave them silent otherwise. I still think keeping them silent for the benefit of end-users is a good thing as long as we make it easier for developers to switch on warnings without thinking about it.

Ethan Furman

8:07 p.m.

New subject: When to remove deprecated stuff

On 08/15/2013 05:40 AM, Brett Cannon wrote:

...

What we should probably do is have unittest turn deprecations on by default when running your tests but leave them silent otherwise. I still think keeping them silent for the benefit of end-users is a good thing as long as we make it easier for developers to switch on warnings without thinking about it.

Michael Foord

16 Aug 16 Aug

2:57 a.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

On 15 Aug 2013, at 15:40, Brett Cannon wrote:

...

On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou wrote: On Thu, 15 Aug 2013 08:29:35 -0400 "R. David Murray" wrote:

...
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...
On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't.

Which is why we shouldn't silence deprecation warnings.

What we should probably do is have unittest turn deprecations on by default when running your tests but leave them silent otherwise.

Hmmm.... I thought we already did this. I guess not. Anyway, I concur. Michael

...

I still think keeping them silent for the benefit of end-users is a good thing as long as we make it easier for developers to switch on warnings without thinking about it. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...

-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

Ezio Melotti

4:53 a.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

On Thu, Aug 15, 2013 at 3:40 PM, Brett Cannon wrote:

...

On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou wrote:

...
...
A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't.

Which is why we shouldn't silence deprecation warnings.

What we should probably do is have unittest turn deprecations on by default when running your tests but leave them silent otherwise.

http://bugs.python.org/issue10535 (I put the keys of the time machine back at their usual place) Best Regards, Ezio Melotti

...

I still think keeping them silent for the benefit of end-users is a good thing as long as we make it easier for developers to switch on warnings without thinking about it.

Brett Cannon

15 Aug 15 Aug

6:08 p.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

On Thu, Aug 15, 2013 at 8:29 AM, R. David Murray wrote:

...

On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...
On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

Incremental has one benefit, and that's we get to completely stop caring sooner. =) By completely removing the module sooner lessens the chance of errant bug reports, etc. Doing the removal en-masse at massive release boundaries is that compatibility for the stdlib can be stated as "Python 3" instead of "Python 3.3 and older" for those that continue to rely on the older modules. I also don't know if we would want to extend this to intra-module objects as well (e.g. classes). In which case we would need to clearly state that anything deprecated is considered dead and under active bitrot and so do not expect it to necessarily work with the rest of the module (e.g. new APIs to work with the deprecated ones).

Ezio Melotti

6:45 p.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

Hi, On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray wrote:

...

On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...
On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

A while ago I wrote an email to python-dev about our deprecation policy: http://mail.python.org/pipermail/python-dev/2011-October/114199.html My idea was to turn this into an informational PEP but I didn't receive much feedback. If people are interested I could still do it. Best Regards, Ezio Melotti

...

If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

--David

Brett Cannon

8:52 p.m.

New subject: When to remove deprecated stuff (was: Deprecating the formatter module)

On Thu, Aug 15, 2013 at 9:15 AM, Ezio Melotti wrote:

...

Hi,

On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray wrote:

...
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...
On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

A while ago I wrote an email to python-dev about our deprecation policy: http://mail.python.org/pipermail/python-dev/2011-October/114199.html

My idea was to turn this into an informational PEP but I didn't receive much feedback. If people are interested I could still do it.

Wouldn't hurt, but should probably be a part of PEP 4.

Terry Reedy

11:04 p.m.

New subject: When to remove deprecated stuff

On 8/15/2013 8:29 AM, R. David Murray wrote:

...

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to 12 years, which is 7 to 10 years after any regular 2.7 maintainance ends. The deprecated unittest synonyms are documented as being removed in 4.0 and that already defines 4.0 as a future cruft-removal release. However, I would not want it defined as the only cruft-removal release and used as a reason or excuse to suspend removals until then. I would personally prefer to do little* removals incrementally, as was done before the decision to put off 2.x removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft removal release, but not the only one. * Removing one or two pure synonyms or little used features from a module. The unittest synonym removal is not 'little' because there are 13 synonyms and at least some were well used.

...

If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

Little removals will usually break something, but not most things. Yes, I think it better to upset a few people with each release than lots of people all at once. I think enabling deprecation notices in unittest is a great idea. Among other reasons, it should spread the effect of bigger removals scheduled farther in the future over the extended deprecation period. Most deprecation notices should provide an alternative. (There might be an exception is for things that should not be done ;-). For module removals, the alternative should be a legacy package on PyPI. -- Terry Jan Reedy

R. David Murray

16 Aug 16 Aug

midnight

New subject: When to remove deprecated stuff

On Thu, 15 Aug 2013 13:34:12 -0400, Terry Reedy wrote:

...

On 8/15/2013 8:29 AM, R. David Murray wrote:

...
A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to 12 years, which is 7 to 10 years after any regular 2.7 maintainance ends.

The deprecated unittest synonyms are documented as being removed in 4.0 and that already defines 4.0 as a future cruft-removal release. However, I would not want it defined as the only cruft-removal release and used as a reason or excuse to suspend removals until then. I would personally prefer to do little* removals incrementally, as was done before the decision to put off 2.x removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft removal release, but not the only one.

* Removing one or two pure synonyms or little used features from a module. The unittest synonym removal is not 'little' because there are 13 synonyms and at least some were well used.

Yes, by "removing cruft" I mostly had in mind the bigger cruft, like whole modules or stuff that is likely to break a lot of existing code. --David

Petri Lehtinen

22 Aug 22 Aug

4:30 p.m.

New subject: When to remove deprecated stuff

Terry Reedy wrote:

...

On 8/15/2013 8:29 AM, R. David Murray wrote:

...
A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to 12 years, which is 7 to 10 years after any regular 2.7 maintainance ends.

The deprecated unittest synonyms are documented as being removed in 4.0 and that already defines 4.0 as a future cruft-removal release. However, I would not want it defined as the only cruft-removal release and used as a reason or excuse to suspend removals until then. I would personally prefer to do little* removals incrementally, as was done before the decision to put off 2.x removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft removal release, but not the only one.

* Removing one or two pure synonyms or little used features from a module. The unittest synonym removal is not 'little' because there are 13 synonyms and at least some were well used.

...
If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

Little removals will usually break something, but not most things. Yes, I think it better to upset a few people with each release than lots of people all at once. I think enabling deprecation notices in unittest is a great idea. Among other reasons, it should spread the effect of bigger removals scheduled farther in the future over the extended deprecation period.

Most deprecation notices should provide an alternative. (There might be an exception is for things that should not be done ;-). For module removals, the alternative should be a legacy package on PyPI.

Removing some cruft on each release can be very painful for users. Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django. I hope the same will not start happening each time I upgrade Python. When the removals happen on major version boundaries, it should be more evident that something will break. Then people can enable DepreationWarnings and test all the affected code thoroughly with the new version before upgrading. Petri

Antoine Pitrou

5:21 p.m.

New subject: When to remove deprecated stuff

Le Thu, 22 Aug 2013 14:00:06 +0300, Petri Lehtinen a écrit :

...

Terry Reedy wrote:

...
On 8/15/2013 8:29 AM, R. David Murray wrote:

...
A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to 12 years, which is 7 to 10 years after any regular 2.7 maintainance ends.

The deprecated unittest synonyms are documented as being removed in 4.0 and that already defines 4.0 as a future cruft-removal release. However, I would not want it defined as the only cruft-removal release and used as a reason or excuse to suspend removals until then. I would personally prefer to do little* removals incrementally, as was done before the decision to put off 2.x removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft removal release, but not the only one.

* Removing one or two pure synonyms or little used features from a module. The unittest synonym removal is not 'little' because there are 13 synonyms and at least some were well used.

...
If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

Little removals will usually break something, but not most things. Yes, I think it better to upset a few people with each release than lots of people all at once. I think enabling deprecation notices in unittest is a great idea. Among other reasons, it should spread the effect of bigger removals scheduled farther in the future over the extended deprecation period.

Most deprecation notices should provide an alternative. (There might be an exception is for things that should not be done ;-). For module removals, the alternative should be a legacy package on PyPI.

Removing some cruft on each release can be very painful for users.

Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

So, again, perhaps we can stop silencing DeprecationWarning. Regards Antoine.

Michael Foord

7:15 p.m.

New subject: When to remove deprecated stuff

On 22 Aug 2013, at 14:00, Petri Lehtinen wrote:

...

Terry Reedy wrote:

...
On 8/15/2013 8:29 AM, R. David Murray wrote:

...
A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to 12 years, which is 7 to 10 years after any regular 2.7 maintainance ends.

The deprecated unittest synonyms are documented as being removed in 4.0 and that already defines 4.0 as a future cruft-removal release. However, I would not want it defined as the only cruft-removal release and used as a reason or excuse to suspend removals until then. I would personally prefer to do little* removals incrementally, as was done before the decision to put off 2.x removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft removal release, but not the only one.

* Removing one or two pure synonyms or little used features from a module. The unittest synonym removal is not 'little' because there are 13 synonyms and at least some were well used.

...
If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

Little removals will usually break something, but not most things. Yes, I think it better to upset a few people with each release than lots of people all at once. I think enabling deprecation notices in unittest is a great idea. Among other reasons, it should spread the effect of bigger removals scheduled farther in the future over the extended deprecation period.

Most deprecation notices should provide an alternative. (There might be an exception is for things that should not be done ;-). For module removals, the alternative should be a legacy package on PyPI.

Removing some cruft on each release can be very painful for users.

Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult? Why not check for the deprecation warnings? Michael

...

I hope the same will not start happening each time I upgrade Python. When the removals happen on major version boundaries, it should be more evident that something will break. Then people can enable DepreationWarnings and test all the affected code thoroughly with the new version before upgrading.

Petri _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...

R. David Murray

8:13 p.m.

New subject: When to remove deprecated stuff

On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord wrote:

...

On 22 Aug 2013, at 14:00, Petri Lehtinen wrote:

...
Terry Reedy wrote:

...
On 8/15/2013 8:29 AM, R. David Murray wrote:

...
A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to 12 years, which is 7 to 10 years after any regular 2.7 maintainance ends.

The deprecated unittest synonyms are documented as being removed in 4.0 and that already defines 4.0 as a future cruft-removal release. However, I would not want it defined as the only cruft-removal release and used as a reason or excuse to suspend removals until then. I would personally prefer to do little* removals incrementally, as was done before the decision to put off 2.x removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft removal release, but not the only one.

* Removing one or two pure synonyms or little used features from a module. The unittest synonym removal is not 'little' because there are 13 synonyms and at least some were well used.

...
If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

Little removals will usually break something, but not most things. Yes, I think it better to upset a few people with each release than lots of people all at once. I think enabling deprecation notices in unittest is a great idea. Among other reasons, it should spread the effect of bigger removals scheduled farther in the future over the extended deprecation period.

Most deprecation notices should provide an alternative. (There might be an exception is for things that should not be done ;-). For module removals, the alternative should be a legacy package on PyPI.

Removing some cruft on each release can be very painful for users.

Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?

Why not check for the deprecation warnings?

Doing so makes very little difference. This is my opinion (others obviously differ): Putting in one big chunk of effort at a major release boundary is easier to schedule than putting in a chunk of effort on *every* feature release. More importantly, having it happen only at the major release boundary means there's only one hard deadline every ten-ish years, rather than a hard deadline every 1.5 years. Expecting things to break when you switch to the new feature release makes one view feature releases with dread rather than excitement. This applies whether or not one is testing with deprecation warnings on. Yes, there's a little less pressure if you are making the fixes on the deprecation release boundary, because you can always ship the code anyway if it is winds up being too big of a bear, so you have more scheduling flexibility. But you still face the *psychological* hurdle of "feature release upgrade...will need to fix the all the things they've deprecated...let's put that off". Especially since what we are talking about here is the *big* cruft, and thus more likely to be a pain to fix. So, the operant question is which do the majority of *users* prefer, some required "fix my code" work at every feature release, or the ability to schedule the "fix my code" work at their convenience, with a hard deadline (for anything not already fixed) at the major release boundary? Note that under this suggested scenario the amount of work people will need to do for Python4 will be trivial compared to that for Python3, and there won't be any controversy about single-code-base vs conversion, because we'll still be maintaining backward compatibility and just removing cruft. So the user base will probably heave a sigh of relief (those that were around for this transition, at least :) rather than a groan. On the other hand, it *does* make a Python4 transition still a big deal ("that package doesn't support Python4 yet, it still uses old cruft XXX".) Ports sure will be easier than with Python3, though! Also, even without removing big cruft, there *will* be things that need to be fixed when switching to a new feature release, so I'm really talking about relative levels of pain and when the bigger pain occurs. How does one judge what the optimal amount of change is? It would be great if we could figure out how to figure out what the users want. We more or less have one user opinion so far, from Petri, based on his experience as a Django user. We developers are also users, of course, but our opinions are colored by our needs as developers as well, so we aren't reliable judges. --David PS: When thinking about this, remember that our effective policy for (the second half of?) Python2 was to hold all the big cruft removal until Python3. Even some stuff that was originally scheduled to be removed sooner got left in. So our user base is currently used to things being pretty stable from a deprecation/backward compatibility standpoint.

Ezio Melotti

11:30 p.m.

New subject: When to remove deprecated stuff

On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray wrote:

...

On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord wrote:

...
On 22 Aug 2013, at 14:00, Petri Lehtinen wrote:

...
Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?

Why not check for the deprecation warnings?

Doing so makes very little difference.

This is my opinion (others obviously differ):

Putting in one big chunk of effort at a major release boundary is easier to schedule than putting in a chunk of effort on *every* feature release.

IMHO there is a third (and better option) that you are missing. Assume I'm using A.B, and see some DeprecationWarnings. Now I have at least 1.5 years to fix them before A.B+1 is released, and once that happens there shouldn't be any warnings left so I can upgrade successfully. Once I do, more warnings will pop up, but then again I will have 1.5+ years to fix them. It seems to me that the problem only arises when the developers ignore (or possibly are unaware of) the warnings until it's time to upgrade.

...

More importantly, having it happen only at the major release boundary means there's only one hard deadline every ten-ish years, rather than a hard deadline every 1.5 years.

[...]

How does one judge what the optimal amount of change is?

It would be great if we could figure out how to figure out what the users want. We more or less have one user opinion so far, from Petri, based on his experience as a Django user. We developers are also users, of course, but our opinions are colored by our needs as developers as well, so we aren't reliable judges.

As I see it there are 3 groups: 1) developers writing libraries/frameworks/interpreters; 2) developers using these libraries/frameworks/interpreters; 3) end users using the applications wrote by the developers. The first group is responsible of warning the second group of the things that got deprecated and give them enough time to update their code. The second group is responsible to listen to the warnings and update their code accordingly. The third group is responsible to sit back and enjoy our hard work without seeing warnings/errors. Best Regards, Ezio Melotti

...

--David

PS: When thinking about this, remember that our effective policy for (the second half of?) Python2 was to hold all the big cruft removal until Python3. Even some stuff that was originally scheduled to be removed sooner got left in. So our user base is currently used to things being pretty stable from a deprecation/backward compatibility standpoint.

R. David Murray

23 Aug 23 Aug

12:10 a.m.

New subject: When to remove deprecated stuff

On Thu, 22 Aug 2013 20:00:14 +0200, Ezio Melotti wrote:

...

On Thu, Aug 22, 2013 at 4:43 PM, R. David Murray wrote:

...
On Thu, 22 Aug 2013 16:45:29 +0300, Michael Foord wrote:

...
On 22 Aug 2013, at 14:00, Petri Lehtinen wrote:

...
Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?

Why not check for the deprecation warnings?

Doing so makes very little difference.

This is my opinion (others obviously differ):

Putting in one big chunk of effort at a major release boundary is easier to schedule than putting in a chunk of effort on *every* feature release.

IMHO there is a third (and better option) that you are missing.

Assume I'm using A.B, and see some DeprecationWarnings. Now I have at least 1.5 years to fix them before A.B+1 is released, and once that happens there shouldn't be any warnings left so I can upgrade successfully. Once I do, more warnings will pop up, but then again I will have 1.5+ years to fix them.

It seems to me that the problem only arises when the developers ignore (or possibly are unaware of) the warnings until it's time to upgrade.

I think you missed my point. It is the *change itself* that causes action to be needed. If a project has a policy of dealing with deprecated features when the warnings happen, then they need to do that work before the version where the feature is removed is released. If they have a policy of ignoring deprecation warnings, then they have to do that work before their users can upgrade to the version where the feature is removed. So the pain exists in equal measure either way, with the same periodicity, only the timing of when the work is done is affected by whether or not you pay attention to deprecation warnings. And yes, you presumably have a more relaxed fix schedule and happier users if you pay attention to deprecation warnings, so you should do that (IMO). I'm asking if the bigger removals should be only on major version boundaries, thus allowing *more* time for that relaxed fix mode for the stuff that takes more work to fix. It does occur to me that this would mean we'd bikeshed about whether any given change was major or not...but we'd do that anyway, because we'd argue about h^h^h^h^h^h^h^h^h discuss how many releases to wait before actually removing it, depending on how disruptive it was likely to be. --David

Stephen J. Turnbull

5:07 a.m.

New subject: When to remove deprecated stuff

R. David Murray writes:

...

It is the *change itself* that causes action to be needed. If a project has a policy of dealing with deprecated features when the warnings happen, then they need to do that work before the version where the feature is removed is released. If they have a policy of ignoring deprecation warnings, then they have to do that work before their users can upgrade to the version where the feature is removed. So the pain exists in equal measure either way, with the same periodicity, only the timing of when the work is done is affected by whether or not you pay attention to deprecation warnings.

This is exactly correct analysis. Changing the DeprecationWarning policy is not going to save anybody any work, and it's not likely to silence the grumbling. It's the feature removal that causes the extra work and that is what causes the complaints.

...

And yes, you presumably have a more relaxed fix schedule and happier users if you pay attention to deprecation warnings, so you should do that (IMO).

Sure, but human nature doesn't work that way. Some people will, others won't, and the latter are likely to think they have reason to complain.

...

I'm asking if the bigger removals should be only on major version boundaries, thus allowing *more* time for that relaxed fix mode for the stuff that takes more work to fix.

My take is that it's not going to help that much. You just don't know what's going to take more work to fix. A trivial-to-fix problem in a proprietary library abandoned by its developer can take a complete rewrite of your program.

Petri Lehtinen

11:08 a.m.

New subject: When to remove deprecated stuff

R. David Murray wrote:

...

...
So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?

Why not check for the deprecation warnings?

Doing so makes very little difference.

This is my opinion (others obviously differ):

Putting in one big chunk of effort at a major release boundary is easier to schedule than putting in a chunk of effort on *every* feature release. More importantly, having it happen only at the major release boundary means there's only one hard deadline every ten-ish years, rather than a hard deadline every 1.5 years.

Expecting things to break when you switch to the new feature release makes one view feature releases with dread rather than excitement.

This applies whether or not one is testing with deprecation warnings on. Yes, there's a little less pressure if you are making the fixes on the deprecation release boundary, because you can always ship the code anyway if it is winds up being too big of a bear, so you have more scheduling flexibility. But you still face the *psychological* hurdle of "feature release upgrade...will need to fix the all the things they've deprecated...let's put that off". Especially since what we are talking about here is the *big* cruft, and thus more likely to be a pain to fix.

These are my thoughts exactly. Maybe I exaggerated a bit about Django. I was slightly unaware of the deprecation policy when Django 1.3 came out (IIRC it was the first release that actually removed deprecated stuff after 1.0). Nowadays I read release notes carefully and do what's needed, and nothing has broken badly ever since. What's really bothering me is that I have to change something in my code every time I upgrade Django. So as David said, it's more like "sigh, a new feature release again" than "yay, new cool features!". Or actually, it's a combination of both because I really want the new features. Petri

Chris Angelico

22 Aug 22 Aug

8:37 p.m.

New subject: When to remove deprecated stuff

On Thu, Aug 22, 2013 at 11:45 PM, Michael Foord wrote:

...

On 22 Aug 2013, at 14:00, Petri Lehtinen wrote:

...
Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3. So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

So you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?

Why not check for the deprecation warnings?

Sounds like the DeprecationWarnings give you just one version of advance notice. You would have to be (a) upgrading every version as it comes out, and (b) checking your log of warnings prior to every upgrade. Neither A.B nor A.B+1 will help you even if you check the warnings. So it would still require checking the full release notes every time, if you want to know about what's being deprecated. Seems a lot of annoying breakage to me. Python is frequently not upgraded release-by-release. I've had servers jump several versions at a time; my oldest server now is running 3.1.1 (and 2.6.4), so when it eventually gets upgraded, it'll probably jump to 3.3 or 3.4. Unless something's producing visible warnings all the way back to 3.1, removal in 3.4 has the potential to be surprising. ChrisA

Ezio Melotti

11:04 p.m.

New subject: When to remove deprecated stuff

Hi, On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen wrote:

...

Removing some cruft on each release can be very painful for users.

Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3.

I see two problems with this: 1) DeprecationWarnings should be generated as soon as the feature is deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not helping anyone. 2) The deprecation period seems fixed and independent from the feature. IMHO the period should vary depending on what is being deprecated. Little known/used "features" could be deprecated in A.B and removed in A.B+1; common "features" can be deprecated in A.B and removed in A.B+n, with an n >= 2 (or even wait for A+1).

...

So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

Reading the release notes shouldn't be required -- DeprecationWarnings are already supposed to tell you what to change. If you have good test coverage this should happen automatically (at least with unittest), but even if you don't you should run your code with -Wa before upgrading (or test your code on the new version before upgrading Python/Django/etc. in production). Best Regards, Ezio Melotti

...

I hope the same will not start happening each time I upgrade Python. When the removals happen on major version boundaries, it should be more evident that something will break. Then people can enable DepreationWarnings and test all the affected code thoroughly with the new version before upgrading.

Petri

Donald Stufft

11:15 p.m.

New subject: When to remove deprecated stuff

On Aug 22, 2013, at 1:34 PM, Ezio Melotti wrote:

...

Hi,

On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen wrote:

...
Removing some cruft on each release can be very painful for users.

Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3.

I see two problems with this: 1) DeprecationWarnings should be generated as soon as the feature is deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not helping anyone. 2) The deprecation period seems fixed and independent from the feature. IMHO the period should vary depending on what is being deprecated. Little known/used "features" could be deprecated in A.B and removed in A.B+1; common "features" can be deprecated in A.B and removed in A.B+n, with an n >= 2 (or even wait for A+1).

This isn't exactly accurate, it raises a PendingDeprecation warning in A.B, Deprecation in A.B+1, and removed in A.B+2. PendingDeprecation (In Django) was designed to be silent by default and Deprecation loud by default. That got messed up when Python silenced Deprecation warnings by default and we've had to resort to some ugliness to restore that behavior.

...

...
So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

Reading the release notes shouldn't be required -- DeprecationWarnings are already supposed to tell you what to change. If you have good test coverage this should happen automatically (at least with unittest), but even if you don't you should run your code with -Wa before upgrading (or test your code on the new version before upgrading Python/Django/etc. in production).

Best Regards, Ezio Melotti

...
I hope the same will not start happening each time I upgrade Python. When the removals happen on major version boundaries, it should be more evident that something will break. Then people can enable DepreationWarnings and test all the affected code thoroughly with the new version before upgrading.

Petri

Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Ezio Melotti

11:44 p.m.

New subject: When to remove deprecated stuff

On Thu, Aug 22, 2013 at 7:45 PM, Donald Stufft wrote:

...

On Aug 22, 2013, at 1:34 PM, Ezio Melotti wrote:

...
Hi,

On Thu, Aug 22, 2013 at 1:00 PM, Petri Lehtinen wrote:

...
Removing some cruft on each release can be very painful for users.

Django's deprecation policy works like this: They deprecate something in version A.B. It still works normally in A.B+1, generates a (silenced) DeprecationWarning in A.B+2, and is finally removed in A.B+3.

I see two problems with this: 1) DeprecationWarnings should be generated as soon as the feature is deprecated (i.e. A.B, not A.B+2). Holding off the warnings is not helping anyone. 2) The deprecation period seems fixed and independent from the feature. IMHO the period should vary depending on what is being deprecated. Little known/used "features" could be deprecated in A.B and removed in A.B+1; common "features" can be deprecated in A.B and removed in A.B+n, with an n >= 2 (or even wait for A+1).

This isn't exactly accurate, it raises a PendingDeprecation warning in A.B, Deprecation in A.B+1, and removed in A.B+2.

PendingDeprecation (In Django) was designed to be silent by default and Deprecation loud by default. That got messed up when Python silenced Deprecation warnings by default and we've had to resort to some ugliness to restore that behavior.

So it's not much different from what we do now, except that we basically stopped using PendingDeprecationWarning -> DeprecationWarning and just use DeprecationWarnings from the beginning. I don't see many advantages in keeping the pending deprecation warnings silent for developers, as it just encourages procrastination :) One advantage is that under your scheme, one can assume that what shows up as deprecated (not pending deprecated) will be removed in the next version, so you could focus your work on them first, but this doesn't work for our scheme were a deprecated "feature" might stay there for a couple of versions. Maybe we should introduce a ``.removed_in`` attribute to DeprecationWarnings? We some times mention it in the deprecation message and the docs, but there's no way to get that information programmatically. Best Regards, Ezio Melotti

...

...
...
So if I haven't read through the full release notes of each release nor enabled DeprecationWarnings, I end up having something broken each time I upgrade Django.

Reading the release notes shouldn't be required -- DeprecationWarnings are already supposed to tell you what to change. If you have good test coverage this should happen automatically (at least with unittest), but even if you don't you should run your code with -Wa before upgrading (or test your code on the new version before upgrading Python/Django/etc. in production).

Best Regards, Ezio Melotti

...
I hope the same will not start happening each time I upgrade Python. When the removals happen on major version boundaries, it should be more evident that something will break. Then people can enable DepreationWarnings and test all the affected code thoroughly with the new version before upgrading.

Petri

Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

MRAB

15 Aug 15 Aug

11:47 p.m.

New subject: When to remove deprecated stuff

On 15/08/2013 13:29, R. David Murray wrote:

...

On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou wrote:

...
On Thu, 15 Aug 2013 11:16:20 +0200 Victor Stinner wrote:

...
2013/8/15 Antoine Pitrou :

...
We don't have any substantial change in store for an eventual "Python 4", so it's quite a remote hypothesis right now.

I prefered the transition between Linux 2 and Linux 3 (no major change, just a "normal" release except the version), rather than the transition between KDE 3 and KDE 4 (in short, everything was broken, the desktop was not usable).

I prefer to not start a list of things that we will make the transition from Python 3 to Python 4 harder. Can't we do small changes between each Python release, even between major versions?

That's exactly what I'm saying. But some changes cannot be made without breakage, e.g. the unicode transition. Then it makes sense to bundle all breaking changes in a single version change.

A number of us (I don't know how many) have clearly been thinking about "Python 4" as the time when we remove cruft. This will not cause any backward compatibility issues for anyone who has paid heed to the deprecation warnings, but will for those who haven't. The question then becomes, is it better to "bundle" these removals into the Python 4 release, or do them incrementally?

If we are going to do them incrementally we should make that decision soonish, so that we don't end up having a whole bunch happen at once and defeat the (theoretical) purpose of doing them incrementally.

(I say theoretical because what is the purpose? To spread out the breakage pain over multiple releases, so that every release breaks something?)

Talking of cruft, would that include these methods of the Thread class? getName() setName() isDaemon() setDaemon()

Skip Montanaro

14 Aug 14 Aug

10:11 p.m.

...

We then realized that it isn't really used by anyone (pydoc uses it but it should have been using textwrap). Looking at the history of the module it has just been a magnet for cleanup revisions and not actual usage or development since Guido added it back in 1995.

Note that it is/was used in Grail, whose most recent release appears to have been 1999: http://grail.sourceforge.net/ I'm not suggesting this is an overriding reason to keep it, just noting that it has seen significant use at one time by a rather prominent Python developer (who was apparently not at your sprint). :-) Skip

3898

Age (days ago)

3909

Last active (days ago)

List overview

Download

53 comments

22 participants

participants (22)

Antoine Pitrou
Brett Cannon
Chris Angelico
Donald Stufft
Eli Bendersky
Ethan Furman
Ezio Melotti
Larry Hastings
Michael Foord
MRAB
Nick Coghlan
Paul Moore
Petri Lehtinen
Phil Elson
R. David Murray
Ryan
Serhiy Storchaka
Skip Montanaro
Stephen J. Turnbull
Steven D'Aprano
Terry Reedy
Victor Stinner

Deprecating the formatter module

tags

participants (22)