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'
On Thu, 15 Aug 2013 11:28:52 +1000
Steven D'Aprano st...@pearwood.info 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
2013/8/15 Antoine Pitrou solip...@pitrou.net:
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
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner victor.stin...@gmail.com wrote:
2013/8/15 Antoine Pitrou solip...@pitrou.net:
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
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
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
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
On Thu, Aug 15, 2013 at 2:25 AM, Steven D'Aprano st...@pearwood.infowrote:
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
On Thu, Aug 15, 2013 at 5:22 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner victor.stin...@gmail.com wrote:
2013/8/15 Antoine Pitrou solip...@pitrou.net:
We don't have any substantial change in store for an eventual Python
4, so it's
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner victor.stin...@gmail.com wrote:
2013/8/15 Antoine Pitrou solip...@pitrou.net:
We don't have any substantial change in store for an eventual Python
4, so it's
On Thu, 15 Aug 2013 08:29:35 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner victor.stin...@gmail.com wrote:
2013/8/15 Antoine Pitrou solip...@pitrou.net:
On Thu, Aug 15, 2013 at 8:29 AM, R. David Murray rdmur...@bitdance.comwrote:
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner victor.stin...@gmail.com wrote:
2013/8/15 Antoine Pitrou solip...@pitrou.net:
On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 15 Aug 2013 08:29:35 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner
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
Hi,
On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner victor.stin...@gmail.com wrote:
2013/8/15 Antoine Pitrou solip...@pitrou.net:
On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith e...@trueblade.com 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
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
On 15 August 2013 05:03, Eric V. Smith e...@trueblade.com 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
On Aug 15, 2013, at 10:59 AM, Eli Bendersky eli...@gmail.com wrote:
On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith e...@trueblade.com 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
On Thu, Aug 15, 2013 at 9:15 AM, Ezio Melotti ezio.melo...@gmail.comwrote:
Hi,
On Thu, Aug 15, 2013 at 3:29 PM, R. David Murray rdmur...@bitdance.com
wrote:
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner
On Thu, Aug 15, 2013 at 8:15 AM, Eric V. Smith e...@trueblade.com wrote:
On Aug 15, 2013, at 10:59 AM, Eli Bendersky eli...@gmail.com wrote:
On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith e...@trueblade.com wrote:
On 8/15/2013 12:27 AM, Nick Coghlan wrote:
I think Eric is
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
On Aug 15, 2013, at 11:36 AM, Eli Bendersky eli...@gmail.com wrote:
On Thu, Aug 15, 2013 at 8:15 AM, Eric V. Smith e...@trueblade.com wrote:
On Aug 15, 2013, at 10:59 AM, Eli Bendersky eli...@gmail.com wrote:
On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith e...@trueblade.com
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
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
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
On 08/15/2013 11:06 AM, Nick Coghlan wrote:
On 15 August 2013 05:03, Eric V. Smith e...@trueblade.com 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
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
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano st...@pearwood.infowrote:
- 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
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 st...@pearwood.info 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
On Thu, Aug 15, 2013 at 6:48 PM, Ryan rym...@gmail.com 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
On 08/15/2013 01:58 PM, Mark Dickinson wrote:
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano st...@pearwood.info
mailto:st...@pearwood.info wrote:
- Each scheme ended up needing to be a separate function, for ease
of both implementation and testing. So I had four private median
On 15/08/2013 13:29, R. David Murray wrote:
On Thu, 15 Aug 2013 11:22:14 +0200, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 15 Aug 2013 11:16:20 +0200
Victor Stinner victor.stin...@gmail.com wrote:
2013/8/15 Antoine Pitrou solip...@pitrou.net:
We don't have any substantial change in
On Thu, 15 Aug 2013 14:10:39 -0400, Eric V. Smith e...@trueblade.com wrote:
On 08/15/2013 01:58 PM, Mark Dickinson wrote:
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano st...@pearwood.info
mailto:st...@pearwood.info wrote:
- Each scheme ended up needing to be a separate
On Thu, 15 Aug 2013 13:34:12 -0400, Terry Reedy tjre...@udel.edu 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
On Thu, 15 Aug 2013 14:24:50 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 15 Aug 2013 14:10:39 -0400, Eric V. Smith e...@trueblade.com
wrote:
On 08/15/2013 01:58 PM, Mark Dickinson wrote:
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano st...@pearwood.info
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
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
On 8/15/2013 2:24 PM, R. David Murray wrote:
On Thu, 15 Aug 2013 14:10:39 -0400, Eric V. Smith e...@trueblade.com
wrote:
On 08/15/2013 01:58 PM, Mark Dickinson wrote:
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano st...@pearwood.info
mailto:st...@pearwood.info wrote:
- Each scheme
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
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
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
On Thu, Aug 15, 2013 at 3:40 PM, Brett Cannon br...@python.org wrote:
On Thu, Aug 15, 2013 at 8:36 AM, Antoine Pitrou solip...@pitrou.netwrote:
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
+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.
On Thu, 15 Aug 2013 23:28:39 +0300, Michael Foord fuzzy...@voidspace.org.uk
wrote:
On 15 Aug 2013, at 21:10, Eric V. Smith e...@trueblade.com wrote:
On 08/15/2013 01:58 PM, Mark Dickinson wrote:
On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano st...@pearwood.info
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
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
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
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(),
On Thu, Aug 15, 2013 at 7:44 PM, Steven D'Aprano st...@pearwood.infowrote:
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
50 matches
Mail list logo
