Re: [Python-Dev] format, int, and IntEnum

[Glenn Linderman]

On 8/14/2013 9:27 PM, Nick Coghlan wrote:


I think Eric is overinterpreting the spec, there. While that 
particular sentence requires that the empty format string will be 
equivalent to a plain str() operation for builtin types, it is only a 
recommendation for other types. For enums, I believe they should be 
formatted like their base types (so !s and !r will show the enum name, 
anything without coercion will show the value) .


Cheers,
Nick.

I could agree with the above for IntEnum, but Enum doesn't have a "base 
type", it has a contained type, no?
___
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] format, int, and IntEnum

[Nick Coghlan]

I think Eric is overinterpreting the spec, there. While that particular
sentence requires that the empty format string will be equivalent to a
plain str() operation for builtin types, it is only a recommendation for
other types. For enums, I believe they should be formatted like their base
types (so !s and !r will show the enum name, anything without coercion will
show the value) .

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

Re: [Python-Dev] format and int subclasses (Was: format, int, and IntEnum)

[Eli Bendersky]

On Wed, Aug 14, 2013 at 4:01 PM, Serhiy Storchaka wrote:

> 15.08.13 01:07, Ethan Furman написав(ла):
>
>>  From http://bugs.python.org/**issue18738
>> :
>>
>
> Actually the problem not only in IntEnum, but in any in subclass.
>
> Currently for empty format specifier int.__format__(x, '') returns str(x).
> But __str__ can be overloaded in a subclass. I think that for less
> surprising we can extend this behavior for format specifier with the width,
> the alignment and the fill character but without the type char. I.e.
> int.__format__(x. '_<10') should return same as format(str(x), '_<10').
>
> The question remains what to do with the sign option. And with the '='
> alignment.
>

Yes, the problem here is certainly not IntEnum - specific; it's just that
IntEnum is the first "for real" use case of subclassing 'int' in the
stdlib. Consider this toy example:

class IntSubclass(int):
def __str__(self):
return 'foo'

s = IntSubclass(42)

print('{:}'.format(s))
print('{:10}'.format(s))

This prints:

foo
42

Which is, IMHO, madness.

In the issue, Eric pointed out that PEP 3101 says "For all built-in types,
an empty format specification will produce the equivalent of str(value)",
and that {:10} is not an "empty format specification", but this looks much
more like a simple bug to me.

Following the "format terminology", I consider the format specification
empty when the representation type (i.e. 'd', 'x' for ints, or 's' for
string) is empty. Things like field width are completely orthogonal to the
interpretation of the value (in a similar vein to traditional "%10d"
formatting). If the lack of the representation type is interpreted as 'd'
(which seems to be the case), it should always be interpreted as 'd', even
when width is given.

A different question is *whether* it should be interptered as 'd'.
Arguably, in the presence of subclasses of 'int', this may not be
desirable. But this behavior seems to be officially documented so we may
not have much to do about it. (*) Well, except making it logically
consistent as specified above.

Eli

(*) So to get the str() for sure, user code will have to explicitly force
the 's' representation type - {:s}, etc. It's not a big burden, and not
really different from "%s" % obj.
___
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] PEP 450 adding statistics module

[Terry Reedy]

On 8/14/2013 9:25 PM, Steven D'Aprano wrote:


The tests aren't
yet integrated with the test runner but are runnable manually.


What do you mean? With the changes I gave you, they run fine as part of 
the test suite.


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

[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

[Python-Dev] PEP 450 adding statistics module

[Steven D'Aprano]

Hi all,

I have raised a tracker item and PEP for adding a statistics module to the 
standard library:

http://bugs.python.org/issue18606

http://www.python.org/dev/peps/pep-0450/

There has been considerable discussion on python-ideas, which is now reflected 
by the PEP. I've signed the Contributor Agreement, and submitted a patch 
containing updated code and tests. The tests aren't yet integrated with the 
test runner but are runnable manually.

Can I request that people please look at this issue, with an aim to ruling on 
the PEP and (hopefully) adding the module to 3.4 before feature freeze? If it 
is accepted, I am willing to be primary maintainer for this module in the 
future.


Thanks,


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

[Python-Dev] format and int subclasses (Was: format, int, and IntEnum)

[Serhiy Storchaka]

15.08.13 01:07, Ethan Furman написав(ла):

 From http://bugs.python.org/issue18738:


Actually the problem not only in IntEnum, but in any in subclass.

Currently for empty format specifier int.__format__(x, '') returns 
str(x). But __str__ can be overloaded in a subclass. I think that for 
less surprising we can extend this behavior for format specifier with 
the width, the alignment and the fill character but without the type 
char. I.e. int.__format__(x. '_<10') should return same as 
format(str(x), '_<10').


The question remains what to do with the sign option. And with the '=' 
alignment.



___
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] format, int, and IntEnum

[Ethan Furman]

From http://bugs.python.org/issue18738:

Ethan Furman commented:

--> class Test(enum.IntEnum):
...   one = 1
...   two = 2
...

--> '{}'.format(Test.one)
'Test.one'

--> '{:d}'.format(Test.one)
'1'

--> '{:}'.format(Test.one)
'Test.one'

--> '{:10}'.format(Test.one)
' 1'


Eric V. Smith commented:

The value of int is always used, except when the format string is empty. PEP 3101 explicitly 
requires this behavior. "For all built-in types, an empty format specification will produce 
the equivalent of str(value)." The "built-in type" here refers to int, since IntEnum 
is derived from int (at least I think it is: I haven't followed the metaclass and multiple 
inheritance completely).


Ethan Furman commented:

So what you're saying is that '{:}' is empty, but '{:10}' is not?


Eric V. Smith commented:

Yes, exactly. The part before the colon says which argument to .format()
to use. The empty string there means "use the next one". The part after the
colon is the format specifier. In the first example above, there's an empty
string after the colon, and in the second example there's a "10" after the
colon.

Which is why it's really easier to use:
format(obj, '')
and
format(obj, '10')
instead of .format examples. By using the built-in format, you only need
to write the format specifier, not the ''.format() "which argument am I
processing" stuff with the braces and colons.


Eli Bendersky commented:

Eric, I'd have to disagree with this part. Placing strictly formal
interpretation of "empty" aside, it seems to me unacceptable that
field-width affects the interpretation of the string. This appears more
like bug in the .format implementation than the original intention. I
suspect that at this point it may be useful to take this discussion to
pydev to get more opinions.


___
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] Dealing with import lock deadlock in Import Hooks

[Antoine Pitrou]

Le Wed, 14 Aug 2013 14:17:59 +0900,
Arnaud Fontaine  a écrit :
> Antoine Pitrou  writes:
> 
> > Le Tue, 13 Aug 2013 17:28:42 +0900, Arnaud Fontaine
> >  a écrit :
> >> Yes. Actually, I was thinking about implementing something similar
> >> to what has been done in Python 3.3 but for Python 2.7 with a
> >> corser-grain lock. From my understanding of import.c, it should
> >> work but I was hoping that someone with more experience in import
> >> code would confirm:
> >
> > It's probably possible, but it will be non-trivial and delicate to
> > get right.
> 
> From my understanding of import.c source code, until something is
> added to sys.modules or the code loaded, there should be no
> side-effect to releasing the lock, right? (eg there is no global
> variables/data being shared for importing modules, meaning that
> releasing the lock should be safe as long as the modules loaded
> through import hooks are protected by a lock)

Er, probably, but import.c is a nasty pile of code.
It's true the import lock is there mainly to:
- avoid incomplete modules from being seen by other threads
- avoid a module from being executed twice

But that doesn't mean it can't have had any other - unintended -
benefits ;-)

(also, some import hooks might not be thread-safe, something which they
haven't had to bother about until 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] Dealing with import lock deadlock in Import Hooks

[Arnaud Fontaine]

Antoine Pitrou  writes:

> Le Tue, 13 Aug 2013 17:28:42 +0900, Arnaud Fontaine 
>  a écrit :
>> Yes. Actually, I was thinking about implementing something similar to
>> what has been done in Python 3.3 but for Python 2.7 with a
>> corser-grain lock. From my understanding of import.c, it should work
>> but I was hoping that someone with more experience in import code
>> would confirm:
>
> It's probably possible, but it will be non-trivial and delicate to get
> right.

From my understanding of import.c source code, until something is added
to sys.modules or the code loaded, there should be no side-effect to
releasing the lock, right? (eg there is no global variables/data being
shared for importing modules, meaning that releasing the lock should be
safe as long as the modules loaded through import hooks are protected by
a lock)

>> Also, if a patch backporting the features from Python 3.3 to import.c
>> for Python 2.7 would be written, is there any chance it could be
>> accepted?
>
> Definitely not. We generally don't backport any features, especially
> when the risk is high due to a feature's implementation complexity.

I see, thanks for your answer.

Regards,
-- 
Arnaud Fontaine
___
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