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

[Serhiy Storchaka]

15.08.13 06:23, Eli Bendersky написав(ла):

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.


Even not the first.

>> '{}'.format(True)
'True'
>>> '{:10}'.format(True)
' 1'


___
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

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

[Eric V. Smith]

On 8/15/2013 12:27 AM, 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) .

I don't think I'm over-interpreting the spec (but of course I'd say
that!). The spec is very precise on the meaning of "format specifier":
it means the entire string (the second argument to __format__). I'll
grant that in the sentence in question it uses "format specification",
not "format specifier", though.

I think this interpretation also meshes with builtin-in "format": with
no format_spec argument, it uses an zero-length string as the default
specifically to get the str(obj) behavior.

Using bool as an example because it's easier to type:

>>> format(True)
'True'
>>> format(True, '10')
' 1'

I think it was Guido who specifically wanted this behavior, although of
course now I can't find the email about it. The closest I could find is
Talin (PEP 3101 author) requesting it:
http://mail.python.org/pipermail/python-3000/2007-August/010121.html.

http://docs.python.org/3/library/string.html#format-specification-mini-language
says 'A general convention is that an empty format string ("") produces
the same result as if you had called str() on the value. A non-empty
format string typically modifies the result.' Again, the wording is not
very tight, but it is talking about format specifiers here.

I still think the best thing to do is implement __format__ for IntEnum,
and there implement whatever behavior is decided. I don't think changing
the meaning of existing objects (specifically int here) is a good course
of action.

Whether we can implement code that breaks existing format specifiers
that would work for "int" but won't work for "str" is open to debate.
See http://bugs.python.org/msg195225. Personally, I think it's okay, but
if you think IntEnum needs to be an exact replacement for int, maybe not.

-- 
Eric.
___
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

[Mark Dickinson]

The PEP and code look generally good to me.

I think the API for median and its variants deserves some wider discussion:
the reference implementation has a callable 'median', and variant callables
'median.low', 'median.high', 'median.grouped'.  The pattern of attaching
the variant callables as attributes on the main callable is unusual, and
isn't something I've seen elsewhere in the standard library.  I'd like to
see some explanation in the PEP for why it's done this way.  (There was
already some discussion of this on the issue, but that was more centered
around the implementation than the API.)

I'd propose two alternatives for this:  either have separate functions
'median', 'median_low', 'median_high', etc., or have a single function
'median' with a "method" argument that takes a string specifying
computation using a particular method.  I don't see a really good reason to
deviate from standard patterns here, and fear that users would find the
current API surprising.

Mark



On Thu, Aug 15, 2013 at 2:25 AM, Steven D'Aprano wrote:

> 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/**
> dickinsm%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] PEP 450 adding statistics module

[Steven D'Aprano]

On 15/08/13 11:49, Terry Reedy wrote:

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.


I'm sorry Terry, at the time I posted I hadn't seen your patch, my apologies.


--
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] PEP 450 adding statistics module

[Mark Dickinson]

On Thu, Aug 15, 2013 at 2:25 AM, Steven D'Aprano wrote:

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

Bah.  I seem to have forgotten how to not top-post.  Apologies.  Please
ignore the previous message, and I'll try again...

The PEP and code look generally good to me.

I think the API for median and its variants deserves some wider discussion:
the reference implementation has a callable 'median', and variant callables
'median.low', 'median.high', 'median.grouped'.  The pattern of attaching
the variant callables as attributes on the main callable is unusual, and
isn't something I've seen elsewhere in the standard library.  I'd like to
see some explanation in the PEP for why it's done this way.  (There was
already some discussion of this on the issue, but that was more centered
around the implementation than the API.)

I'd propose two alternatives for this:  either have separate functions
'median', 'median_low', 'median_high', etc., or have a single function
'median' with a "method" argument that takes a string specifying
computation using a particular method.  I don't see a really good reason to
deviate from standard patterns here, and fear that users would find the
current API surprising.

Mark
___
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 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] When to remove deprecated stuff (was: Deprecating the formatter module)

[R. David Murray]

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
___
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] When to remove deprecated stuff (was: Deprecating the formatter module)

[Antoine Pitrou]

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.


___
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] When to remove deprecated stuff (was: Deprecating the formatter module)

[Brett Cannon]

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).
___
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] When to remove deprecated stuff (was: Deprecating the formatter module)

[Brett Cannon]

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

[Steven D'Aprano]

On 15/08/13 21:42, Mark Dickinson wrote:

The PEP and code look generally good to me.

I think the API for median and its variants deserves some wider discussion:
the reference implementation has a callable 'median', and variant callables
'median.low', 'median.high', 'median.grouped'.  The pattern of attaching
the variant callables as attributes on the main callable is unusual, and
isn't something I've seen elsewhere in the standard library.  I'd like to
see some explanation in the PEP for why it's done this way.  (There was
already some discussion of this on the issue, but that was more centered
around the implementation than the API.)

I'd propose two alternatives for this:  either have separate functions
'median', 'median_low', 'median_high', etc., or have a single function
'median' with a "method" argument that takes a string specifying
computation using a particular method.  I don't see a really good reason to
deviate from standard patterns here, and fear that users would find the
current API surprising.


Alexander Belopolsky has convinced me (off-list) that my current implementation 
is better changed to a more conservative one of a callable singleton instance 
with methods implementing the alternative computations. I'll have something 
like:


def _singleton(cls):
return cls()


@_singleton
class median:
def __call__(self, data):
...
def low(self, data):
...
...


In my earlier stats module, I had a single median function that took a argument to choose 
between alternatives. I called it "scheme":

median(data, scheme="low")

R uses parameter called "type" to choose between alternate calculations, not 
for median as we are discussing, but for quantiles:

quantile(x, probs ... type = 7, ...).

SAS also uses a similar system, but with different numeric codes. I rejected both "type" 
and "method" as the parameter name since it would cause confusion with the usual meanings 
of those words. I eventually decided against this system for two reasons:

- Each scheme ended up needing to be a separate function, for ease of both implementation 
and testing. So I had four private median functions, which I put inside a class to act as 
namespace and avoid polluting the main namespace. Then I needed a "master 
function" to select which of the methods should be called, with all the additional 
testing and documentation that entailed.

- The API doesn't really feel very Pythonic to me. For example, we write:

mystring.rjust(width)
dict.items()

rather than mystring.justify(width, "right") or dict.iterate("items"). So I 
think individual methods is a better API, and one which is more familiar to most Python users. The 
only innovation (if that's what it is) is to have median a callable object.


As far as having four separate functions, median, median_low, etc., it just 
doesn't feel right to me. It puts four slight variations of the same function 
into the main namespace, instead of keeping them together in a namespace. Names 
like median_low merely simulates a namespace with pseudo-methods separated with 
underscores instead of dots, only without the advantages of a real namespace.

(I treat variance and std dev differently, and make the sample and population 
forms separate top-level functions rather than methods, simply because they are 
so well-known from scientific calculators that it is unthinkable to me to do 
differently. Whenever I use numpy, I am surprised all over again that it has 
only a single variance function.)



--
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] When to remove deprecated stuff (was: Deprecating the formatter module)

[Ezio Melotti]

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

[Eli Bendersky]

On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith  wrote:

> On 8/15/2013 12:27 AM, 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) .
>
> I don't think I'm over-interpreting the spec (but of course I'd say
> that!). The spec is very precise on the meaning of "format specifier":
> it means the entire string (the second argument to __format__). I'll
> grant that in the sentence in question it uses "format specification",
> not "format specifier", though.
>
> I think this interpretation also meshes with builtin-in "format": with
> no format_spec argument, it uses an zero-length string as the default
> specifically to get the str(obj) behavior.
>
> Using bool as an example because it's easier to type:
>
> >>> format(True)
> 'True'
> >>> format(True, '10')
> ' 1'
>
>
Eric, which-ever way you interpret the spec, the above violates the
least-surprise principle; do you agree? It's easily one of those things
that makes the "WTF, Python?" lists. Do you disagree?

Unfortunately, I don't think there's a lot we can do about it now. It's a
design mistake, locked with backwards compatibility until "Python 4".

For IntEnum, being in control of __format__ and being a new class, I
suppose we can create any behavior we want here. Can we do more? Is it even
conceivable to rig the boolean sub-type to change this behavior to be more
rational? I suspect that no, but one can hope ;-)
And in any case, the documentation has to be tightened a bit formally to
express what we mean exactly, how it translates to the behavior of builtin
types, and what is allowed for custom types.

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] When to remove deprecated stuff

[Ethan Furman]

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.


+1
___
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]

On 15 August 2013 05:03, Eric V. Smith  wrote:
> On 8/15/2013 12:27 AM, 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) .
>
> I don't think I'm over-interpreting the spec (but of course I'd say
> that!). The spec is very precise on the meaning of "format specifier":
> it means the entire string (the second argument to __format__). I'll
> grant that in the sentence in question it uses "format specification",
> not "format specifier", though.

By overinterpreting, I meant interpreting that part to mean literally
calling str() when the specifier was empty, but not calling it
otherwise. That's not what it means: it means that "str(x)" and
"format(x)" will typically produce the *same result*, not that format
will actually call str. If a subclass overrides __str__ but not
__format__ (or vice-versa), then they can and *should* diverge.

So, ideally, we would be more consistent, and either *always* call
str() for subclasses when no type specifier is given, or *never* call
it and always use the value.

In this case, for integers, a missing type specifier for numeric types
is defined as meaning "d", so calling str() on subclasses is wrong -
it should be using the value, not the string representation. So "no
type specifier" + "int subclass" *should* have meant calling int(self)
prior to formatting rather than str(self), and subtypes look bool
would have needed to override both __str__ and __format__.

The problem now is that changing this behaviour in the base class
would break subclasses like bool that expect format(x) to produce the
same result as str(x) even though they have overridden __str__ but not
__format__.

So, I think the path to consistency here needs to be that, if a
builtin subclass overrides __str__ without overriding __format__, then
the formatting result will *always* be "format(str(x), fmtspec)",
regardless of whether fmtspec is empty or not. This will make bool
formatting work as expected, even when using things like the field
width specifiers.

There's a slight backwards compatibility risk even with that more
conservative change, though - attempting to use numeric formatting
codes with affected subtypes will now throw an exception, and for
codes common to numbers and strings the output will change :(

>>> format(True, "10")
' 1'
>>> format(str(True), "10")
'True  '
>>> format(True, "10,")
' 1'
>>> format(str(True), "10,")
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Cannot specify ',' with 's'.

So we may just have to live with the wart and tell people to always
override both to ensure consistent behaviour :(

> I still think the best thing to do is implement __format__ for IntEnum,
> and there implement whatever behavior is decided. I don't think changing
> the meaning of existing objects (specifically int here) is a good course
> of action.

I don't think changing the processing of int is proposed - just the
handling of subclasses. However, since it seems to me that "make bool
formatting work consistently" is a more conservative change (if we
change the base class behaviour at all), then Enum subclasses will
need __format__ defined regardless.

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

[Eric V. Smith]

On Aug 15, 2013, at 10:59 AM, Eli Bendersky  wrote:

> 
> 
> 
> On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith  wrote:
>> On 8/15/2013 12:27 AM, 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) .
>> 
>> I don't think I'm over-interpreting the spec (but of course I'd say
>> that!). The spec is very precise on the meaning of "format specifier":
>> it means the entire string (the second argument to __format__). I'll
>> grant that in the sentence in question it uses "format specification",
>> not "format specifier", though.
>> 
>> I think this interpretation also meshes with builtin-in "format": with
>> no format_spec argument, it uses an zero-length string as the default
>> specifically to get the str(obj) behavior.
>> 
>> Using bool as an example because it's easier to type:
>> 
>> >>> format(True)
>> 'True'
>> >>> format(True, '10')
>> ' 1'
> 
> Eric, which-ever way you interpret the spec, the above violates the 
> least-surprise principle; do you agree? It's easily one of those things that 
> makes the "WTF, Python?" lists. Do you disagree?

Oh, I completely agree that it doesn't make much sense, and is surprising. I 
was just trying to explain why we see the current behavior. 

> Unfortunately, I don't think there's a lot we can do about it now. It's a 
> design mistake, locked with backwards compatibility until "Python 4".

Agreed. 

> For IntEnum, being in control of __format__ and being a new class, I suppose 
> we can create any behavior we want here.

Right. That's the intent. I'd personally be okay with checking for int format 
codes (bdxX, etc.) and treating it as an int, otherwise a string. As I've 
pointed out, it's slightly fragile, and there are a few cases where a valid int 
format spec will give an error when treating it as a string, but that doesn't 
bother me.  

> Can we do more? Is it even conceivable to rig the boolean sub-type to change 
> this behavior to be more rational? I suspect that no, but one can hope ;-)

I don't think there's much we can do, unfortunately. I think bool should work 
the same as the proposed IntEnum changes, but that's an incompatible change. 

> And in any case, the documentation has to be tightened a bit formally to 
> express what we mean exactly, how it translates to the behavior of builtin 
> types, and what is allowed for custom types.

I'm okay with that. 

Eric.

___
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] When to remove deprecated stuff (was: Deprecating the formatter module)

[Brett Cannon]

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

[Eli Bendersky]

On Thu, Aug 15, 2013 at 8:15 AM, Eric V. Smith  wrote:

> On Aug 15, 2013, at 10:59 AM, Eli Bendersky  wrote:
>
>
>
>
> On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith  wrote:
>
>> On 8/15/2013 12:27 AM, 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) .
>>
>> I don't think I'm over-interpreting the spec (but of course I'd say
>> that!). The spec is very precise on the meaning of "format specifier":
>> it means the entire string (the second argument to __format__). I'll
>> grant that in the sentence in question it uses "format specification",
>> not "format specifier", though.
>>
>> I think this interpretation also meshes with builtin-in "format": with
>> no format_spec argument, it uses an zero-length string as the default
>> specifically to get the str(obj) behavior.
>>
>> Using bool as an example because it's easier to type:
>>
>> >>> format(True)
>> 'True'
>> >>> format(True, '10')
>> ' 1'
>>
>>
> Eric, which-ever way you interpret the spec, the above violates the
> least-surprise principle; do you agree? It's easily one of those things
> that makes the "WTF, Python?" lists. Do you disagree?
>
>
> Oh, I completely agree that it doesn't make much sense, and is surprising.
> I was just trying to explain why we see the current behavior.
>
> Unfortunately, I don't think there's a lot we can do about it now. It's a
> design mistake, locked with backwards compatibility until "Python 4".
>
>
> Agreed.
>
> For IntEnum, being in control of __format__ and being a new class, I
> suppose we can create any behavior we want here.
>
>
> Right. That's the intent. I'd personally be okay with checking for int
> format codes (bdxX, etc.) and treating it as an int, otherwise a string. As
> I've pointed out, it's slightly fragile, and there are a few cases where a
> valid int format spec will give an error when treating it as a string, but
> that doesn't bother me.
>

This got me thinking when we were discussing it in the issue. It's
plausible that every subclass of builtin types will need to implement
__format__ to act sanely. So maybe we can propose some sort of API (on the
Python level) that makes parsing the format string easy and will not make
code go stale? What do you think?


> Can we do more? Is it even conceivable to rig the boolean sub-type to
> change this behavior to be more rational? I suspect that no, but one can
> hope ;-)
>
>
> I don't think there's much we can do, unfortunately. I think bool should
> work the same as the proposed IntEnum changes, but that's an incompatible
> 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] format, int, and IntEnum

[Ethan Furman]

Given that the !r and !s format codes can be used to get the repr and str of an IntEnum, would it be acceptable to have 
IntEnum's __format__ simply pass through to int's __format__?  And likewise with all mix-in classes?


--
~Ethan~
___
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

[Eric V. Smith]

On Aug 15, 2013, at 11:36 AM, Eli Bendersky  wrote:

> 
> 
> 
> On Thu, Aug 15, 2013 at 8:15 AM, Eric V. Smith  wrote:
>> On Aug 15, 2013, at 10:59 AM, Eli Bendersky  wrote:
>> 
>>> 
>>> 
>>> 
>>> On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith  wrote:
 On 8/15/2013 12:27 AM, 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) .
 
 I don't think I'm over-interpreting the spec (but of course I'd say
 that!). The spec is very precise on the meaning of "format specifier":
 it means the entire string (the second argument to __format__). I'll
 grant that in the sentence in question it uses "format specification",
 not "format specifier", though.
 
 I think this interpretation also meshes with builtin-in "format": with
 no format_spec argument, it uses an zero-length string as the default
 specifically to get the str(obj) behavior.
 
 Using bool as an example because it's easier to type:
 
 >>> format(True)
 'True'
 >>> format(True, '10')
 ' 1'
>>> 
>>> Eric, which-ever way you interpret the spec, the above violates the 
>>> least-surprise principle; do you agree? It's easily one of those things 
>>> that makes the "WTF, Python?" lists. Do you disagree?
>> 
>> Oh, I completely agree that it doesn't make much sense, and is surprising. I 
>> was just trying to explain why we see the current behavior. 
>> 
>>> Unfortunately, I don't think there's a lot we can do about it now. It's a 
>>> design mistake, locked with backwards compatibility until "Python 4".
>> 
>> Agreed. 
>> 
>>> For IntEnum, being in control of __format__ and being a new class, I 
>>> suppose we can create any behavior we want here.
>> 
>> Right. That's the intent. I'd personally be okay with checking for int 
>> format codes (bdxX, etc.) and treating it as an int, otherwise a string. As 
>> I've pointed out, it's slightly fragile, and there are a few cases where a 
>> valid int format spec will give an error when treating it as a string, but 
>> that doesn't bother me. 
> 
> This got me thinking when we were discussing it in the issue. It's plausible 
> that every subclass of builtin types will need to implement __format__ to act 
> sanely. So maybe we can propose some sort of API (on the Python level) that 
> makes parsing the format string easy and will not make code go stale? What do 
> you think?

I've proposed this in the past, primarily for Decimal. I'd be okay with it. It 
would need to done carefully to allow us to expand the format string, for 
example when we added ','. Maybe return a namedtuple or equivalent. 

But remember, not all types understand the same format strings. datetime being 
the classic case. 

> 
>> 
>>> Can we do more? Is it even conceivable to rig the boolean sub-type to 
>>> change this behavior to be more rational? I suspect that no, but one can 
>>> hope ;-)
>> 
>> I don't think there's much we can do, unfortunately. I think bool should 
>> work the same as the proposed IntEnum changes, but that's an incompatible 
>> change. 
> 
> :-(

I know. Me, too. 

Eric. ___
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

[Eli Bendersky]

> This got me thinking when we were discussing it in the issue. It's
> plausible that every subclass of builtin types will need to implement
> __format__ to act sanely. So maybe we can propose some sort of API (on the
> Python level) that makes parsing the format string easy and will not make
> code go stale? What do you think?
>
>
> I've proposed this in the past, primarily for Decimal. I'd be okay with
> it. It would need to done carefully to allow us to expand the format
> string, for example when we added ','. Maybe return a namedtuple or
> equivalent.
>
> But remember, not all types understand the same format strings. datetime
> being the classic case.
>
>
Sure, this is why I specifically restricted it to subclasses of builtin
types, because these should presumably understand the flags used for
builtin types. Anyway, we'll see how much parsing will have to be done in
practice for IntEnum - it can serve as a guinea pig.

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

[Python-Dev] Issue 13248: 3.4 Removals?

[Terry Reedy]

Related to the current deprecation discussion:
http://bugs.python.org/issue13248

This is a master list of deprecated items scheduled for removal in 3.4. 
Anything that is going to be removed should be done now, before the next 
alpha, methinks.


--
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] When to remove deprecated stuff

[Terry Reedy]

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

___
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

[Eric V. Smith]

On 08/15/2013 11:06 AM, Nick Coghlan wrote:
> On 15 August 2013 05:03, Eric V. Smith  wrote:
>> On 8/15/2013 12:27 AM, 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) .
>>
>> I don't think I'm over-interpreting the spec (but of course I'd say
>> that!). The spec is very precise on the meaning of "format specifier":
>> it means the entire string (the second argument to __format__). I'll
>> grant that in the sentence in question it uses "format specification",
>> not "format specifier", though.
> 
> By overinterpreting, I meant interpreting that part to mean literally
> calling str() when the specifier was empty, but not calling it
> otherwise. That's not what it means: it means that "str(x)" and
> "format(x)" will typically produce the *same result*, not that format
> will actually call str. If a subclass overrides __str__ but not
> __format__ (or vice-versa), then they can and *should* diverge.
> 
> So, ideally, we would be more consistent, and either *always* call
> str() for subclasses when no type specifier is given, or *never* call
> it and always use the value.
> 
> In this case, for integers, a missing type specifier for numeric types
> is defined as meaning "d", so calling str() on subclasses is wrong -
> it should be using the value, not the string representation. So "no
> type specifier" + "int subclass" *should* have meant calling int(self)
> prior to formatting rather than str(self), and subtypes look bool
> would have needed to override both __str__ and __format__.

I'm pretty sure that when I implemented this we went over this point in
extreme detail, and that we specifically wanted it to apply to an empty
"format specifier", not an empty "type specifier" (which the PEP and the
documentation call a "presentation type"). Your interpretation might
make more sense, but it's not what we discussed at the time (to my
recollection), and I think it's too late to change now, unfortunately.

> The problem now is that changing this behaviour in the base class
> would break subclasses like bool that expect format(x) to produce the
> same result as str(x) even though they have overridden __str__ but not
> __format__.
> 
> So, I think the path to consistency here needs to be that, if a
> builtin subclass overrides __str__ without overriding __format__, then
> the formatting result will *always* be "format(str(x), fmtspec)",
> regardless of whether fmtspec is empty or not. This will make bool
> formatting work as expected, even when using things like the field
> width specifiers.
> 
> There's a slight backwards compatibility risk even with that more
> conservative change, though - attempting to use numeric formatting
> codes with affected subtypes will now throw an exception, and for
> codes common to numbers and strings the output will change :(
> 
 format(True, "10")
> ' 1'
 format(str(True), "10")
> 'True  '
 format(True, "10,")
> ' 1'
 format(str(True), "10,")
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: Cannot specify ',' with 's'.
> 
> So we may just have to live with the wart and tell people to always
> override both to ensure consistent behaviour :(

I think that's true.

>> I still think the best thing to do is implement __format__ for IntEnum,
>> and there implement whatever behavior is decided. I don't think changing
>> the meaning of existing objects (specifically int here) is a good course
>> of action.
> 
> I don't think changing the processing of int is proposed - just the
> handling of subclasses. However, since it seems to me that "make bool
> formatting work consistently" is a more conservative change (if we
> change the base class behaviour at all), then Enum subclasses will
> need __format__ defined regardless.

Agreed. And I think the real discussion here needs to be: what should
__format__ for IntEnum (or maybe Enum) do? Is not being consistent with
what int.__format__ accepts okay? (For example, "+" or "10,".) Or does
being a "drop-in replacement for int" mean that any format string for
int must also work for IntEnum? As I've said, I think breaking a few
format strings is okay, but of course it's debatable.

Eric.

___
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

[Eric V. Smith]

On 08/15/2013 11:21 AM, Ethan Furman wrote:
> Given that the !r and !s format codes can be used to get the repr and
> str of an IntEnum, would it be acceptable to have IntEnum's __format__
> simply pass through to int's __format__?  And likewise with all mix-in
> classes?

That helps with str.format(), but not with built-in format(). There,
you'd have to explicitly call str() or repr():


>>> '{:10}'.format(True)
' 1'
>>> format(True, '10')
' 1'

>>> '{!s:10}'.format(True)
'True  '
>>> format(str(True), '10')
'True  '

Eric.




___
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

[Mark Dickinson]

On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano wrote:

>
> - Each scheme ended up needing to be a separate function, for ease of both
> implementation and testing. So I had four private median functions, which I
> put inside a class to act as namespace and avoid polluting the main
> namespace. Then I needed a "master function" to select which of the methods
> should be called, with all the additional testing and documentation that
> entailed.
>

That's just an implementation issue, though, and sounds like a minor
inconvenience to the implementor rather than anything serious;  I don't
think that that should dictate the API that's used.

- The API doesn't really feel very Pythonic to me. For example, we write:
>

And I guess this is subjective:  conversely, the API you're proposing
doesn't feel Pythonic to me. :-)  I'd like the hear the opinion of other
python-dev readers.

Thanks for the detailed replies.  Would it be possible to put some of this
reasoning into the PEP?

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

[Ryan]

For the naming, how about changing median(callable) to median.regular? That 
way, we don't have to deal with a callable namespace.

Steven D'Aprano  wrote:

>On 15/08/13 21:42, Mark Dickinson wrote:
>> The PEP and code look generally good to me.
>>
>> I think the API for median and its variants deserves some wider
>discussion:
>> the reference implementation has a callable 'median', and variant
>callables
>> 'median.low', 'median.high', 'median.grouped'.  The pattern of
>attaching
>> the variant callables as attributes on the main callable is unusual,
>and
>> isn't something I've seen elsewhere in the standard library.  I'd
>like to
>> see some explanation in the PEP for why it's done this way.  (There
>was
>> already some discussion of this on the issue, but that was more
>centered
>> around the implementation than the API.)
>>
>> I'd propose two alternatives for this:  either have separate
>functions
>> 'median', 'median_low', 'median_high', etc., or have a single
>function
>> 'median' with a "method" argument that takes a string specifying
>> computation using a particular method.  I don't see a really good
>reason to
>> deviate from standard patterns here, and fear that users would find
>the
>> current API surprising.
>
>Alexander Belopolsky has convinced me (off-list) that my current
>implementation is better changed to a more conservative one of a
>callable singleton instance with methods implementing the alternative
>computations. I'll have something like:
>
>
>def _singleton(cls):
> return cls()
>
>
>@_singleton
>class median:
> def __call__(self, data):
> ...
> def low(self, data):
> ...
> ...
>
>
>In my earlier stats module, I had a single median function that took a
>argument to choose between alternatives. I called it "scheme":
>
>median(data, scheme="low")
>
>R uses parameter called "type" to choose between alternate
>calculations, not for median as we are discussing, but for quantiles:
>
>quantile(x, probs ... type = 7, ...).
>
>SAS also uses a similar system, but with different numeric codes. I
>rejected both "type" and "method" as the parameter name since it would
>cause confusion with the usual meanings of those words. I eventually
>decided against this system for two reasons:
>
>- Each scheme ended up needing to be a separate function, for ease of
>both implementation and testing. So I had four private median
>functions, which I put inside a class to act as namespace and avoid
>polluting the main namespace. Then I needed a "master function" to
>select which of the methods should be called, with all the additional
>testing and documentation that entailed.
>
>- The API doesn't really feel very Pythonic to me. For example, we
>write:
>
>mystring.rjust(width)
>dict.items()
>
>rather than mystring.justify(width, "right") or dict.iterate("items").
>So I think individual methods is a better API, and one which is more
>familiar to most Python users. The only innovation (if that's what it
>is) is to have median a callable object.
>
>
>As far as having four separate functions, median, median_low, etc., it
>just doesn't feel right to me. It puts four slight variations of the
>same function into the main namespace, instead of keeping them together
>in a namespace. Names like median_low merely simulates a namespace with
>pseudo-methods separated with underscores instead of dots, only without
>the advantages of a real namespace.
>
>(I treat variance and std dev differently, and make the sample and
>population forms separate top-level functions rather than methods,
>simply because they are so well-known from scientific calculators that
>it is unthinkable to me to do differently. Whenever I use numpy, I am
>surprised all over again that it has only a single variance function.)
>
>
>
>-- 
>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/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] PEP 450 adding statistics module

[Mark Dickinson]

On Thu, Aug 15, 2013 at 6:48 PM, Ryan  wrote:

> For the naming, how about changing median(callable) to median.regular?
> That way, we don't have to deal with a callable namespace.
>

Hmm.  That sounds like a step backwards to me:  whatever the API is, a
simple "from statistics import median; m = median(my_data)" should still
work in the simple case.

Mark





>
> Steven D'Aprano  wrote:
>
>> On 15/08/13 21:42, Mark Dickinson wrote:
>>
>>> The PEP and code look generally good to me.
>>>
>>> I think the API for median and its variants deserves some wider discussion:
>>> the reference implementation has a callable 'median', and variant callables
>>> 'median.low', 'median.high', 'median.grouped'.  The pattern of attaching
>>> the variant callables as attributes on the main callable is unusual, and
>>> isn't something I've seen elsewhere in the standard library.  I'd like to
>>> see some explanation in the PEP for why it's done this way.  (There was
>>> already some discussion of this on the issue, but that was more centered
>>> around the implementation than the API.)
>>>
>>> I'd propose two alternatives for this:  either have separate functions
>>> 'median', 'median_low', 'median_high', etc., or have a single function
>>> 'median' with a "method" argument that takes a string specifying
>>> computation using a particular method.  I don't see a really good reason to
>>> deviate from standard patterns here, and fear that users would find the
>>> current API surprising.
>>
>>
>> Alexander Belopolsky has convinced me (off-list) that my current 
>> implementation is better changed to a more conservative one of a callable 
>> singleton instance with methods implementing the alternative computations. 
>> I'll have something like:
>>
>>
>> def _singleton(cls):
>> return cls()
>>
>>
>> @_singleton
>> class median:
>> def __call__(self, data):
>> ...
>> def low(self, data):
>> ...
>> ...
>>
>>
>> In my earlier stats module, I had a single median function that took a 
>> argument to choose between alternatives. I called it "scheme":
>>
>> median(data, scheme="low")
>>
>> R uses parameter
>> called "type" to choose between alternate calculations, not for median as we 
>> are discussing, but for quantiles:
>>
>> quantile(x, probs ... type = 7, ...).
>>
>> SAS also uses a similar system, but with different numeric codes. I rejected 
>> both "type" and "method" as the parameter name since it would cause 
>> confusion with the usual meanings of those words. I eventually decided 
>> against this system for two reasons:
>>
>> - Each scheme ended up needing to be a separate function, for ease of both 
>> implementation and testing. So I had four private median functions, which I 
>> put inside a class to act as namespace and avoid polluting the main 
>> namespace. Then I needed a "master function" to select which of the methods 
>> should be called, with all the additional testing and documentation that 
>> entailed.
>>
>> - The API doesn't really feel very Pythonic to me. For example, we write:
>>
>> mystring.rjust(width)
>> dict.items()
>>
>> rather than mystring.justify(width,
>> "right") or dict.iterate("items"). So I think individual methods is a better 
>> API, and one which is more familiar to most Python users. The only 
>> innovation (if that's what it is) is to have median a callable object.
>>
>>
>> As far as having four separate functions, median, median_low, etc., it just 
>> doesn't feel right to me. It puts four slight variations of the same 
>> function into the main namespace, instead of keeping them together in a 
>> namespace. Names like median_low merely simulates a namespace with 
>> pseudo-methods separated with underscores instead of dots, only without the 
>> advantages of a real namespace.
>>
>> (I treat variance and std dev differently, and make the sample and 
>> population forms separate top-level functions rather than methods, simply 
>> because they are so well-known from scientific calculators that it is 
>> unthinkable to me to do differently. Whenever I use numpy, I am surprised 
>> all over again that it has only a single variance function.)
>>
>>
>>
> --
> 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/dickinsm%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] PEP 450 adding statistics module

[Eric V. Smith]

On 08/15/2013 01:58 PM, Mark Dickinson wrote:
> On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano  > wrote:
> 
> 
> - Each scheme ended up needing to be a separate function, for ease
> of both implementation and testing. So I had four private median
> functions, which I put inside a class to act as namespace and avoid
> polluting the main namespace. Then I needed a "master function" to
> select which of the methods should be called, with all the
> additional testing and documentation that entailed.
> 
> 
> That's just an implementation issue, though, and sounds like a minor
> inconvenience to the implementor rather than anything serious;  I don't
> think that that should dictate the API that's used.
> 
> - The API doesn't really feel very Pythonic to me. For example, we
> write:
> 
> 
> And I guess this is subjective:  conversely, the API you're proposing
> doesn't feel Pythonic to me. :-)  I'd like the hear the opinion of other
> python-dev readers.

I agree with Mark: the proposed median, median.low, etc., doesn't feel
right. Is there any example of doing this in the stdlib? I suggest just
median(), median_low(), etc.

If we do end up keeping it, simpler than the callable singleton is:

>>> def median(): return 'median'
...
>>> def _median_low(): return 'median.low'
...
>>> median.low = _median_low
>>> del _median_low
>>> median()
'median'
>>> median.low()
'median.low'

Eric.

___
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] When to remove deprecated stuff

[MRAB]

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

___
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

[R. David Murray]

On Thu, 15 Aug 2013 14:10:39 -0400, "Eric V. Smith"  wrote:
> On 08/15/2013 01:58 PM, Mark Dickinson wrote:
> > On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano  > > wrote:
> > 
> > 
> > - Each scheme ended up needing to be a separate function, for ease
> > of both implementation and testing. So I had four private median
> > functions, which I put inside a class to act as namespace and avoid
> > polluting the main namespace. Then I needed a "master function" to
> > select which of the methods should be called, with all the
> > additional testing and documentation that entailed.
> > 
> > 
> > That's just an implementation issue, though, and sounds like a minor
> > inconvenience to the implementor rather than anything serious;  I don't
> > think that that should dictate the API that's used.
> > 
> > - The API doesn't really feel very Pythonic to me. For example, we
> > write:
> > 
> > 
> > And I guess this is subjective:  conversely, the API you're proposing
> > doesn't feel Pythonic to me. :-)  I'd like the hear the opinion of other
> > python-dev readers.
> 
> I agree with Mark: the proposed median, median.low, etc., doesn't feel
> right. Is there any example of doing this in the stdlib? I suggest just
> median(), median_low(), etc.

I too prefer the median_low naming rather than median.low.  I'm not
sure I can articulate why, but certainly the fact that that latter
isn't used anywhere else in the stdlib that I can think of is
probably a lot of it :)

Perhaps the underlying thought is that we don't use classes pure
function namespaces:  we expect classes to be something more than
that.

--David
___
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] When to remove deprecated stuff

[R. David Murray]

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

[Antoine Pitrou]

On Thu, 15 Aug 2013 14:24:50 -0400
"R. David Murray"  wrote:
> On Thu, 15 Aug 2013 14:10:39 -0400, "Eric V. Smith"  
> wrote:
> > On 08/15/2013 01:58 PM, Mark Dickinson wrote:
> > > On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano  > > > wrote:
> > > 
> > > 
> > > - Each scheme ended up needing to be a separate function, for ease
> > > of both implementation and testing. So I had four private median
> > > functions, which I put inside a class to act as namespace and avoid
> > > polluting the main namespace. Then I needed a "master function" to
> > > select which of the methods should be called, with all the
> > > additional testing and documentation that entailed.
> > > 
> > > 
> > > That's just an implementation issue, though, and sounds like a minor
> > > inconvenience to the implementor rather than anything serious;  I don't
> > > think that that should dictate the API that's used.
> > > 
> > > - The API doesn't really feel very Pythonic to me. For example, we
> > > write:
> > > 
> > > 
> > > And I guess this is subjective:  conversely, the API you're proposing
> > > doesn't feel Pythonic to me. :-)  I'd like the hear the opinion of other
> > > python-dev readers.
> > 
> > I agree with Mark: the proposed median, median.low, etc., doesn't feel
> > right. Is there any example of doing this in the stdlib? I suggest just
> > median(), median_low(), etc.
> 
> I too prefer the median_low naming rather than median.low.  I'm not
> sure I can articulate why, but certainly the fact that that latter
> isn't used anywhere else in the stdlib that I can think of is
> probably a lot of it :)

Count me in the Agreement Car, with Mark and RDM.

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

[Ethan Furman]

On 08/15/2013 10:44 AM, Eric V. Smith wrote:

On 08/15/2013 11:21 AM, Ethan Furman wrote:

Given that the !r and !s format codes can be used to get the repr and
str of an IntEnum, would it be acceptable to have IntEnum's __format__
simply pass through to int's __format__?  And likewise with all mix-in
classes?


That helps with str.format(), but not with built-in format(). There,
you'd have to explicitly call str() or repr():


Given that !s and !r are explicitly asking for str or repr, I'm okay with that.

--
~Ethan~
___
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

[Eli Bendersky]

>
> > > And I guess this is subjective:  conversely, the API you're proposing
> > > doesn't feel Pythonic to me. :-)  I'd like the hear the opinion of
> other
> > > python-dev readers.
> >
> > I agree with Mark: the proposed median, median.low, etc., doesn't feel
> > right. Is there any example of doing this in the stdlib? I suggest just
> > median(), median_low(), etc.
>
> I too prefer the median_low naming rather than median.low.  I'm not
> sure I can articulate why, but certainly the fact that that latter
> isn't used anywhere else in the stdlib that I can think of is
> probably a lot of it :)
>
> Perhaps the underlying thought is that we don't use classes pure
> function namespaces:  we expect classes to be something more than
> that.
>

Certainly. Python does not force the "everything is a class" philosophy of
Java and Ruby. Classes have their uses, but namespacing isn't it. There are
modules for namespaces.

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] PEP 450 adding statistics module

[Eric V. Smith]

On 8/15/2013 2:24 PM, R. David Murray wrote:
> On Thu, 15 Aug 2013 14:10:39 -0400, "Eric V. Smith"  
> wrote:
>> On 08/15/2013 01:58 PM, Mark Dickinson wrote:
>>> On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano >> > wrote:
>>>
>>>
>>> - Each scheme ended up needing to be a separate function, for ease
>>> of both implementation and testing. So I had four private median
>>> functions, which I put inside a class to act as namespace and avoid
>>> polluting the main namespace. Then I needed a "master function" to
>>> select which of the methods should be called, with all the
>>> additional testing and documentation that entailed.
>>>
>>>
>>> That's just an implementation issue, though, and sounds like a minor
>>> inconvenience to the implementor rather than anything serious;  I don't
>>> think that that should dictate the API that's used.
>>>
>>> - The API doesn't really feel very Pythonic to me. For example, we
>>> write:
>>>
>>>
>>> And I guess this is subjective:  conversely, the API you're proposing
>>> doesn't feel Pythonic to me. :-)  I'd like the hear the opinion of other
>>> python-dev readers.
>>
>> I agree with Mark: the proposed median, median.low, etc., doesn't feel
>> right. Is there any example of doing this in the stdlib? I suggest just
>> median(), median_low(), etc.
> 
> I too prefer the median_low naming rather than median.low.  I'm not
> sure I can articulate why, but certainly the fact that that latter
> isn't used anywhere else in the stdlib that I can think of is
> probably a lot of it :)

Actually, there is one place I can think of:
itertools.chain.from_iterable. But I think that was a mistake, too. As a
recent discussion showed, it's not exactly discoverable. The fact that
it's not mentioned in the list of functions at the top of the
documentation doesn't help. And "chain" is documented as a "module
function", and "chain.from_iterable" as a "classmethod" making it all
the more confusing.

I think itertools.combinations and
itertools.combinations_with_replacement is the better example of related
functions that should be followed. Not nested, no special parameters
trying to differentiate them: just two different function names.

-- 
Eric.
___
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/15/2013 4:16 PM, Eric V. Smith wrote:

itertools.chain.from_iterable. But I think that was a mistake, too. As a
recent discussion showed, it's not exactly discoverable. The fact that
it's not mentioned in the list of functions at the top of the
documentation doesn't help. And "chain" is documented as a "module
function", and "chain.from_iterable" as a "classmethod" making it all
the more confusing.

I think itertools.combinations and
itertools.combinations_with_replacement is the better example of related
functions that should be followed. Not nested, no special parameters
trying to differentiate them: just two different function names.


Great implied idea. I opened http://bugs.python.org/issue18752
"Make chain.from_iterable an alias for a new chain_iterable."

--
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] PEP 450 adding statistics module

[Terry Reedy]

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

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,


I have avoided this discussion, in spite of a decade+ experience as a 
statistician-programmer, because I am quite busy with Idle testing and 
there seem to be enough other knowledgeable people around. But I approve 
of the general idea. I once naively used the shortcut computing formula 
for variance, present in all too many statistics books, in a program I 
supplied to a couple of laboratories. After a few months, maybe even a 
year, of daily use, it crashed trying to take the square root of a 
negative variance*. Whoops. Fortunately, I was still around to quickly 
fix it.


*As I remember, the three value were something like 1, 1, 10001 
as single-precision floats.


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

[Python-Dev] PEP 452 API for Cryptographic Hash Functions v2.0

[Christian Heimes]

Hello,

I have written a revised version of PEP 247. It's heavily based on AMKs
original version from 2001. Version 2.0 adds ``name`` and ``block_size``
as mandatory attributes. It defines that hashing objects operate only on
byte-like objects in Python 3.x, too.

I have also developed an abstract base class for cryptographic hashing
algorithm [1]. Should I add it to the PEP and make it mandatory for
Python 3.4+?

Regards,
Christian

[1] http://bugs.python.org/issue18742

PEP: 452
Title: API for Cryptographic Hash Functions v2.0
Version: $Revision$
Last-Modified: $Date$
Author: A.M. Kuchling , Christian Heimes 
Status: Draft
Type: Informational
Created: 15-Aug-2013
Post-History:
Replaces: 247

Abstract

There are several different modules available that implement
cryptographic hashing algorithms such as MD5 or SHA.  This
document specifies a standard API for such algorithms, to make it
easier to switch between different implementations.


Specification

All hashing modules should present the same interface.  Additional
methods or variables can be added, but those described in this
document should always be present.

Hash function modules define one function:

new([string])(unkeyed hashes)
new([key] , [string])(keyed hashes)

Create a new hashing object and return it.  The first form is
for hashes that are unkeyed, such as MD5 or SHA.  For keyed
hashes such as HMAC, 'key' is a required parameter containing
a string giving the key to use.  In both cases, the optional
'string' parameter, if supplied, will be immediately hashed
into the object's starting state, as if obj.update(string) was
called.

After creating a hashing object, arbitrary bytes can be fed
into the object using its update() method, and the hash value
can be obtained at any time by calling the object's digest()
method.

Although the parameter is called 'string', hashing objects operate
on 8-bit data only. Both 'key' and 'string' must be a bytes-like
object (bytes, bytearray...). A hashing object may support
one-dimensional, contiguous buffers as argument, too. Text
(unicode) is no longer supported in Python 3.x. Python 2.x
implementations may take ASCII-only unicode as argument, but
portable code should not rely on the feature.

Arbitrary additional keyword arguments can be added to this
function, but if they're not supplied, sensible default values
should be used.  For example, 'rounds' and 'digest_size'
keywords could be added for a hash function which supports a
variable number of rounds and several different output sizes,
and they should default to values believed to be secure.

Hash function modules define one variable:

digest_size

An integer value; the size of the digest produced by the
hashing objects created by this module, measured in bytes.
You could also obtain this value by creating a sample object
and accessing its 'digest_size' attribute, but it can be
convenient to have this value available from the module.
Hashes with a variable output size will set this variable to
None.

Hashing objects require the following attribute:

digest_size

This attribute is identical to the module-level digest_size
variable, measuring the size of the digest produced by the
hashing object, measured in bytes.  If the hash has a variable
output size, this output size must be chosen when the hashing
object is created, and this attribute must contain the
selected size.  Therefore None is *not* a legal value for this
attribute.

block_size

An integer value or ``NotImplemented``; the internal block size
of the hash algorithm in bytes. The block size is used by the
HMAC module to pad the secret key to digest_size or to hash the
secret key if it is longer than digest_size. If no HMAC
algorithm is standardized for the the hash algorithm, return
``NotImplemented`` instead.

name

A text string value; the canonical, lowercase name of the hashing
algorithm. The name should be a suitable parameter for
:func:`hashlib.new`.

Hashing objects require the following methods:

copy()

Return a separate copy of this hashing object.  An update to
this copy won't affect the original object.

digest()

Return the hash value of this hashing object as a bytes
containing 8-bit data.  The object is not altered in any way
by this function; you can continue updating the object after
calling this function.

hexdigest()

Return the hash value of this hashing object as a string
containing hexadecimal digits.  Lowercase letters should be used
for 

Re: [Python-Dev] When to remove deprecated stuff (was: Deprecating the formatter module)

[Ezio Melotti]

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

[Nick Coghlan]

+1 for the PEP in general from me, but using the underscore based
pseudo-namespace for the median variants.

The attribute approach isn't *wrong*, just surprising enough that I think
independent functions with the "median_" prefix in their name is a better
idea.

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] PEP 450 adding statistics module

[R. David Murray]

On Thu, 15 Aug 2013 23:28:39 +0300, Michael Foord  
wrote:
> 
> On 15 Aug 2013, at 21:10, "Eric V. Smith"  wrote:
> 
> > On 08/15/2013 01:58 PM, Mark Dickinson wrote:
> >> On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano  >> > wrote:
> >> 
> >> 
> >>- Each scheme ended up needing to be a separate function, for ease
> >>of both implementation and testing. So I had four private median
> >>functions, which I put inside a class to act as namespace and avoid
> >>polluting the main namespace. Then I needed a "master function" to
> >>select which of the methods should be called, with all the
> >>additional testing and documentation that entailed.
> >> 
> >> 
> >> That's just an implementation issue, though, and sounds like a minor
> >> inconvenience to the implementor rather than anything serious;  I don't
> >> think that that should dictate the API that's used.
> >> 
> >>- The API doesn't really feel very Pythonic to me. For example, we
> >>write:
> >> 
> >> 
> >> And I guess this is subjective:  conversely, the API you're proposing
> >> doesn't feel Pythonic to me. :-)  I'd like the hear the opinion of other
> >> python-dev readers.
> > 
> > I agree with Mark: the proposed median, median.low, etc., doesn't feel
> > right. Is there any example of doing this in the stdlib? I suggest just
> > median(), median_low(), etc.
> > 
> > If we do end up keeping it, simpler than the callable singleton is:
> > 
>  def median(): return 'median'
> > ...
>  def _median_low(): return 'median.low'
> > ...
>  median.low = _median_low
>  del _median_low
>  median()
> > 'median'
>  median.low()
> > 'median.low'
> 
> 
> There's the patch decorator in unittest.mock which provides:
> 
>   patch(...)
>   patch.object(...)
>   patch.dict(...)
> 
> The implementation is exactly as you suggest. (e.g. patch.object = 
> _patch_object)

Truthfully there are a number of things about the mock API that make me
uncomfortable, including that one.  But despite that I'm glad we
didn't try to re-engineer it.  Take that as you will :)

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

[Steven D'Aprano]

On 16/08/13 04:10, Eric V. Smith wrote:


I agree with Mark: the proposed median, median.low, etc., doesn't feel
right. Is there any example of doing this in the stdlib?


The most obvious case is datetime: we have datetime(), and datetime.now(), 
datetime.today(), and datetime.strftime(). The only API difference between it 
and median is that datetime is a type and median is not, but that's a 
difference that makes no difference: both are callables, and being a type is an 
implementation detail. dict used to be a function that returned a type. Now it 
is a type. Implementation detail.

Even builtins do this: dict() and dict.fromkeys(), for example. If you include 
unbound methods, nearly every type in Python uses the callable(), 
callable.method() API. I am truly perplexed by the opposition to the median 
API. It's a trivially small difference to a pattern you find everywhere.



If we do end up keeping it, simpler than the callable singleton is:


def median(): return 'median'

...

def _median_low(): return 'median.low'

...

median.low = _median_low
del _median_low
median()

'median'

median.low()

'median.low'


That is the implementation I currently have. Alexander has convinced me that 
attaching functions to functions in this way is sub-optimal, because 
help(median) doesn't notice the attributes, so I'm ruling this implementation 
out.

My preference is to make median a singleton instance with a __call__ method, 
and the other flavours regular methods. Although I don't like polluting the 
global namespace with an unnecessary class that will only be instantiated once, 
if it helps I can do this:

class _Median:
def __call__(self, data): ...
def low(self, data): ...

median = _Median()

If that standard OOP design is unacceptable, I will swap the dots for 
underscores, but I won't like it.



--
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] PEP 450 adding statistics module

[Steven D'Aprano]

On 16/08/13 04:24, R. David Murray wrote:

I too prefer the median_low naming rather than median.low.  I'm not
sure I can articulate why, but certainly the fact that that latter
isn't used anywhere else in the stdlib that I can think of is
probably a lot of it:)


And the reason it's not used in the stdlib is because whenever somebody proposes doing 
so, python-dev says "but it's never been used in the stdlib before".

*wink*



Perhaps the underlying thought is that we don't use classes pure
function namespaces:  we expect classes to be something more than
that.


To be perfectly frank, I agree! Using a class is not my first preference, and 
I'm suspicious of singletons, but classes and instances are the only flexible 
namespace type we have short of modules and packages. We have nothing like C++ 
namespaces. (I have some ideas about that, but they are experimental and 
utterly not appropriate for first-time use in a std lib module.) Considering 
how long the namespaces line has been part of the Zen, Python is surprisingly 
inflexible when it comes to namespaces. There are classes, and modules, and 
nothing in-between.

A separate module for median is too much. There's only four functions. If there were a dozen such 
functions, I'd push them out into a module, but using a full-blown package structure just for the 
sake of median is overkill. It is possible to construct a module object on the fly, but I expect 
that would be even less welcome than a class, and besides, modules aren't callable, which leads to 
such ugly and error-prone constructions as datetime.datetime and friends. I won't impose 
"median.median" or "median.regular" on anyone :-)

Anyway, this is my last defence of median.low() and friends. If consensus is 
still against it, I'll use underscores.

(I will add a section in the PEP about it, one way or the other.)



--
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] PEP 450 adding statistics module

[Terry Reedy]

On 8/15/2013 10:44 PM, Steven D'Aprano wrote:


The most obvious case is datetime: we have datetime(), and
datetime.now(), datetime.today(), and datetime.strftime(). The only API
difference between it and median is that datetime is a type and median
is not, but that's a difference that makes no difference:


I and several others, see them as conceptually different in a way that 
makes a big difference. Datetime is a number structure with distinct 
properties and operations. The median of a set of values from a totally 
ordered set is the middle value (if there is an odd number). The median 
is a function and the result of the function and the type of the result 
depends on the type of the inputs. The only complication is when there 
are an even number of items and the middle two cannot be averaged. I 
presume that is what medium_low is about (pick the lower of the middle 
two). It is a variant function with a more general definition, not a 
method of a type.


None of the above have anything to do with Python implementations.

--
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] PEP 450 adding statistics module

[Eric V. Smith]

On 8/15/2013 10:44 PM, Steven D'Aprano wrote:
> On 16/08/13 04:10, Eric V. Smith wrote:
> 
>> I agree with Mark: the proposed median, median.low, etc., doesn't feel
>> right. Is there any example of doing this in the stdlib?
> 
> The most obvious case is datetime: we have datetime(), and
> datetime.now(), datetime.today(), and datetime.strftime(). The only API
> difference between it and median is that datetime is a type and median
> is not, but that's a difference that makes no difference: both are
> callables, and being a type is an implementation detail. dict used to be
> a function that returned a type. Now it is a type. Implementation detail.
> 
> Even builtins do this: dict() and dict.fromkeys(), for example. 

Except those classmethods are all alternate constructors for the class
of which they're members (it's datetime.strptime, not .strftime). That's
a not uncommon idiom. To me, that's a logical difference from the
proposed median.

I understand it's all just namespaces and callables, but I think the
proposed median(), median.low(), etc. just confuse users and makes
things less discoverable. I'd expect dir(statistics) to tell me all of
the available functions in the module. I wouldn't expect to need to look
inside all of the returned functions to see what other functions exist.

To see what I mean, look at help(itertools), and see how much harder it
is to find chain.from_iterable than it is to find
combination_with_replacement.

BTW, I'm +1 on adding the statistics module.

-- 
Eric.
___
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

[Eli Bendersky]

On Thu, Aug 15, 2013 at 7:44 PM, Steven D'Aprano wrote:

> On 16/08/13 04:10, Eric V. Smith wrote:
>
>  I agree with Mark: the proposed median, median.low, etc., doesn't feel
>> right. Is there any example of doing this in the stdlib?
>>
>
> The most obvious case is datetime: we have datetime(), and datetime.now(),
> datetime.today(), and datetime.strftime(). The only API difference between
> it and median is that datetime is a type and median is not, but that's a
> difference that makes no difference: both are callables, and being a type
> is an implementation detail. dict used to be a function that returned a
> type. Now it is a type. Implementation detail.
>
> Even builtins do this: dict() and dict.fromkeys(), for example. If you
> include unbound methods, nearly every type in Python uses the callable(),
> callable.method() API. I am truly perplexed by the opposition to the median
> API. It's a trivially small difference to a pattern you find everywhere.


Steven, this is a completely inappropriate comparison. datetime.now(),
dict.fromkeys() and others are *factory methods*, also known as alternative
constructors. This is a very common idiom in OOP, especially in languages
where there is no explicit operator overloading for constructors (and even
in those languages, like C++, this idiom is used above some level of
complexity). This is totally unlike using a class as a namespace. The
latter is unpythonic. If you need a namespace, use a module. If you don't
need a namespace, then just use functions. Classes are the wrong tool to
express the namespace abstraction in Python.

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