Re: [Python-Dev] Deprecating the formatter module

[Brett Cannon]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Antoine Pitrou]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Victor Stinner]

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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Antoine Pitrou]

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.


___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Steven D'Aprano]

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
>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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Eli Bendersky]

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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Terry Reedy]

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

___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Brett Cannon]

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).
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Chris Angelico]

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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Skip Montanaro]

> 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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[MRAB]

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




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

On 14 August 2013 11:55, Brett Cannon mailto:br...@python.org>> wrote:
 > On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan
mailto:ncogh...@gmail.com>> wrote:
 >>
 >> On 14 August 2013 11:08, Brett Cannon mailto:br...@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?

___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Brett Cannon]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Eli Bendersky]

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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Nick Coghlan]

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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Brett Cannon]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Nick Coghlan]

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/20130313-language-summit.html#legacy-modules

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Antoine Pitrou]

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.


___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Brett Cannon]

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
>>> >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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Steven D'Aprano]

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/**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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Nick Coghlan]

On 13 Aug 2013 09:39, "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 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).
>
> 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
>
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Brett Cannon]

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/**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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[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 
the formatter module was not removed in Python 3.0 I don't see why it 
can't wait to 4.0.


___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Phil Elson]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Ryan]

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.___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Antoine Pitrou]

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



___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Eli Bendersky]

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
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Larry Hastings]

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/
___
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/archive%40mail-archive.com

Re: [Python-Dev] Deprecating the formatter module

[Paul Moore]

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
___
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/archive%40mail-archive.com

[Python-Dev] Deprecating the formatter module

[Brett Cannon]

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/archive%40mail-archive.com