Eli Bendersky added the comment:
The idea looks reasonable. Posted a code review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Ethan Furman added the comment:
Final (hopefully ;) patch attached. Thanks, Eli, for your comments and help.
--
Added file: http://bugs.python.org/file31538/issue18738.stoneleaf.04.patch
___
Python tracker rep...@bugs.python.org
Ethan Furman added the comment:
Thanks, Eric, for teaching me a bunch about format. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
Ethan Furman added the comment:
Okay, the final final patch. ;)
--
Added file: http://bugs.python.org/file31539/issue18738.stoneleaf.05.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Eli Bendersky added the comment:
lgtm
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric V. Smith added the comment:
Looks good to me, too. Thanks for considering all of the feedback!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
Roundup Robot added the comment:
New changeset 058cb219b3b5 by Ethan Furman in branch 'default':
Close #18738: Route __format__ calls to mixed-in type for mixed Enums (such as
IntEnum).
http://hg.python.org/cpython/rev/058cb219b3b5
--
nosy: +python-dev
resolution: - fixed
stage:
Ethan Furman added the comment:
On 08/14/2013 09:27 PM, on PyDev, Nick Coghlan wrote:
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 agree. While one of the big reasons for an Enum
Serhiy Storchaka added the comment:
print(member)
%s % member
{}.format(member)
Would you seriously use either of those last two in either the debugger
or the command line?
Yes, of course. When you need debug output from function or loop inners.
for ...:
...
Serhiy Storchaka added the comment:
I'm proposing to split this issue on two issues. One for C-style formatting (I
guess everyone agree that '%i' % int-like object should return decimal
representation of its numerical value) and other for format() which is more
questionable.
--
Ethan Furman added the comment:
Serhiy Storchaka added the comment:
I'm proposing to split this issue on two issues. One for C-style formatting
(I guess everyone agree that '%i' % int-like object should return decimal
representation of its numerical value) and other for format() which is
Serhiy Storchaka added the comment:
Not sure that's necessary. The code to fix the C-style %-formatting is
already (I think) in the last patch I attached.
Could you please extract this part of the patch and add tests? It can be
reviewed and committed separately. See also issue18780, there
Eric V. Smith added the comment:
I agree splitting this makes sense, so as to not delay the %-formatting fix.
While similar in principle, the fixes are unrelated. We may as well keep this
issue the __format__ part, since it's been most discussed here.
--
Eli Bendersky added the comment:
On Wed, Aug 21, 2013 at 6:40 AM, Eric V. Smith rep...@bugs.python.orgwrote:
Eric V. Smith added the comment:
I agree splitting this makes sense, so as to not delay the %-formatting
fix. While similar in principle, the fixes are unrelated. We may as well
Eli Bendersky added the comment:
Serhiy, if you feel this is related to #18780 maybe they can be merged into a
single issue (since the comment on #18780 says the fix here will work there
too)?
--
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
I rather think that two discussions about two almost unrelated series of
patches in same issue will be confused.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
Eli Bendersky added the comment:
The whole point of IntEnum and replacing stdlib constants with it was
friendly str repr out of the box.
Sure, friendly str and repr plus an nice way to work them in code.
This means that just printing out an enum member
Ethan Furman added the comment:
Eric V. Smith added the comment:
this gives the (to me) surprising results of:
format(S.a)
'S.a'
format(S.a, '10')
'S.a'
format(S.a, '10s')
'A'
that is surprising: if a __format__ is defined in the Enum class chain
then it should be used instead of the
Eric V. Smith added the comment:
On 8/20/2013 9:26 PM, Ethan Furman wrote:
Sounds like the way forward is to specify in the docs how the default
Enum __format__ behaves (basically honors width and justification
settings to yield the name, anything else passes through to the Enum
member)
Eric V. Smith added the comment:
Oh, I don't feel my time has been wasted. Where else can I have a discussion of
__format__?
With this patch, given this:
class UpperString(str):
def __format__(self, fmt):
return str.__format__(self, fmt).upper()
class UpperEnum(UpperString, Enum):
Serhiy Storchaka added the comment:
For C-style formatting see also issue18780.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Ethan Furman added the comment:
Eric, please do not feel your time has been wasted. I greatly appreciate the
knowledge you shared and I learned much.
I feel very strongly that, as much as possible, an Enum should Just Work.
Requiring users to write their own __format__ any time they create
Ethan Furman added the comment:
This patch contains the previous patch, plus a fix and tests for %i, %d, and %u
formatting, and tests only for %f formatting (nothing to fix there, but don't
want it breaking in the future ;) .
--
Added file:
Ethan Furman added the comment:
+def __format__(self, *args, **kwargs):
+return self.__class__._member_type_.__format__(self.value, *args,
**kwargs)
+
With this in the Enum class all members simply forward formatting to the
mixed-in type, meaning that IntEnum behaves exactly like
Eli Bendersky added the comment:
The whole point of IntEnum and replacing stdlib constants with it was friendly
str repr out of the box. This means that just printing out an enum member
should have a nice string representation. And just printing out means:
print(member)
%s % member
Eric V. Smith added the comment:
On 8/15/2013 5:46 PM, Eli Bendersky wrote:
The whole point of IntEnum and replacing stdlib constants with it was
friendly str repr out of the box. This means that just printing out an
enum member should have a nice string representation. And just printing
Eli Bendersky added the comment:
On Thu, Aug 15, 2013 at 3:20 PM, Eric V. Smith rep...@bugs.python.orgwrote:
Eric V. Smith added the comment:
On 8/15/2013 5:46 PM, Eli Bendersky wrote:
The whole point of IntEnum and replacing stdlib constants with it was
friendly str repr out of the
Ethan Furman added the comment:
Eli Bendersky added the comment:
Naturally, compatibility with % formatting is desired. '%s' is str, '%i' is
int().
Can we solve that one on this issue, or do we need to make another?
--
___
Python tracker
Eli Bendersky added the comment:
I guess there are merits to keeping it all in the same place.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
Ethan Furman added the comment:
Eric V. Smith added the comment:
I think the answers should be:
- Formats as int if the length of the format spec is = 1 and it ends in
one of bdoxX (the int presentation types).
Hmmm. How about defining the characters that will be supported for string
Eric V. Smith added the comment:
On 8/15/2013 7:09 PM, Ethan Furman wrote:
Ethan Furman added the comment:
Eric V. Smith added the comment:
I think the answers should be:
- Formats as int if the length of the format spec is = 1 and it ends in
one of bdoxX (the int presentation types).
Ethan Furman added the comment:
Eric V. Smith added the comment:
Ethan Furman added the comment:
Hmmm. How about defining the characters that will be supported for string
interpretation, and if there are any other
characters in format spec then go int (or whatever the mix-in type is)?
Eric V. Smith added the comment:
On 8/15/2013 8:20 PM, Ethan Furman wrote:
The characters I list are the justification chars and the digits that would
be used to specify the field width. If
those are the only characters given then treat the MixedEnum member as the
member string.
But a
Ethan Furman added the comment:
Eric V. Smith added the comment:
But a datetime format string can end in 0, for example.
format(datetime.datetime.now(), '%H:%M:%S.00')
'20:25:27.00'
Not a problem, because once the digits were removed there would still be % : H
M S and ., so the datetime
Eric V. Smith added the comment:
On 8/16/2013 12:24 AM, Ethan Furman wrote:
Ethan Furman added the comment:
Eric V. Smith added the comment:
But a datetime format string can end in 0, for example.
format(datetime.datetime.now(), '%H:%M:%S.00')
'20:25:27.00'
Not a problem, because
Changes by Eli Bendersky eli...@gmail.com:
--
title: % formatting incomplete for Enum - String formatting (% and str.format)
issues with Enum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
Gotcha. I'm on it.
--
assignee: - ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Ethan Furman added the comment:
The %-formatting needs to be handled by str, correct?
What is '{:}' supposed to mean?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
Eric V. Smith added the comment:
What is '{:}' supposed to mean?
It should be the same as '{}'. That is, an empty format string.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Ethan Furman added the comment:
Which is the same as '%s', yes? In that case, the current behavior of
'{:}'.format(AF.IPv4) is correct, isn't it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
Eric V. Smith added the comment:
I think:
'{:}'.format(AF.IPv4)
'AF.IPv4'
is correct, assuming str(AF.IPv4) is 'AF.IPv4'. I'm not sure what:
'{:10}'.format(AF.IPv4)
should produce. There's a special case for an empty format string calling str().
I think that specifying __format__() would
Ethan Furman added the comment:
Eric V. Smith added the comment:
I think that specifying __format__() would be best, except then you need to
decide what sort of format specification language you want to support, and
deal with all of the implementation details. Or, maybe just have Enum's
Eric V. Smith added the comment:
I think that specifying __format__() would be best, except then you need to
decide what sort of format specification language you want to support, and
deal with all of the implementation details. Or, maybe just have Enum's
__format__ be:
def
Ethan Furman added the comment:
Eric V. Smith added the comment:
For the format version, what gets called is:
int_subclass.__format__('d'), which is int.__format__(int_subclass,
'd'), which produces '1', assuming int(int_subclass) is 1.
Ah, I didn't realize. Thanks.
So, there's no str
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 11:48 AM, Ethan Furman rep...@bugs.python.orgwrote:
Ethan Furman added the comment:
Eric V. Smith added the comment:
For the format version, what gets called is:
int_subclass.__format__('d'), which is
Eric V. Smith added the comment:
For format, I think the question is should an IntEnum format like an int, with
the wacky exception of a specifier of '', or should it always format like a
str?
I assumed we'd want it to look like the str() version of itself, always. But
it's debatable.
I
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 11:56 AM, Eric V. Smith rep...@bugs.python.orgwrote:
Eric V. Smith added the comment:
For format, I think the question is should an IntEnum format like an int,
with the wacky exception of a specifier of '', or should it always format
Ethan Furman added the comment:
Eric V. Smith added the comment:
I assumed we'd want it to look like the str() version of itself, always. But
it's debatable.
An IntEnum's str and repr should be (and any format or % codes that are the
equivalent) the Enum str and repr. The %
and format
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 12:07 PM, Ethan Furman rep...@bugs.python.orgwrote:
Ethan Furman added the comment:
Eric V. Smith added the comment:
I assumed we'd want it to look like the str() version of itself, always.
But it's debatable.
An IntEnum's str
Eric V. Smith added the comment:
I think IntEnum should act like a str for format() purposes. After all, having
a useful string representation is a prime reason it exists. If you want it to
act like a str() sometimes, and an int() at others, you're going to have to
parse the format specifier
Ethan Furman added the comment:
Okay, I see your points. I can certainly agree with going with the str
representation when no numeric code is specified. But, if a numeric code is
specified (x, b, d, etc.) then the numeric value should be used.
Agreed?
--
Ethan Furman added the comment:
On 08/14/2013 11:55 AM, Eli Bendersky wrote:
I'm not sure I understand. The discrepancy between {:} and {:10} is clearly
a problem.
Ah, you're right.
--
___
Python tracker rep...@bugs.python.org
Eli Bendersky added the comment:
Okay, I see your points. I can certainly agree with going with the str
representation when no numeric code is specified. But, if a numeric code
is specified (x, b, d, etc.) then the numeric value should be used.
Agreed?
Yes. I suggest to wait a day or
Eric V. Smith added the comment:
If IntEnum.__format__ is going to parse the format string, it's a little
fragile. For example, say we modify int.__format__ to understand a Z
presentation type. Who's going to remember to update IntEnum.__format__?
For reference, the existing integer formats
Ethan Furman added the comment:
What I'm hoping is to get agreement on what the behavior should be (unspecified
format codes use str or repr, specified
numeric codes use the value), and then persuade folks that int (or PyLong) is
where that behavior should be kept (so int
is subclass
Eric V. Smith added the comment:
I don't think it's possible for int (PyLong) to handle a decision to format
itself as a string. Personally, I'd like this:
format(3, 's')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: Unknown format code 's' for object of type
Changes by Eric V. Smith e...@trueblade.com:
--
assignee: - ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
___
Ethan Furman added the comment:
-- class Test(enum.IntEnum):
... one = 1
... two = 2
...
-- '{}'.format(Test.one)
'Test.one'
-- '{:d}'.format(Test.one)
'1'
-- '{:}'.format(Test.one)
'Test.one'
-- '{:10}'.format(Test.one)
' 1'
Sometimes the str is used, and sometimes the value of
Eric V. Smith added the comment:
The value of int is always used, except when the format string is empty. PEP
3101 explicitly requires this behavior. For all built-in types, an empty
format specification will produce the equivalent of str(value). The built-in
type here refers to int, since
Ethan Furman added the comment:
So what you're saying is that '{:}' is empty, but '{:10}' is not?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18738
___
Eric V. Smith added the comment:
So what you're saying is that '{:}' is empty, but '{:10}' is not?
Yes, exactly. The part before the colon says which argument to .format() to
use. The empty string there means use the next one. The part after the colon
is the format specifier. In the first
Eli Bendersky added the comment:
On Wed, Aug 14, 2013 at 2:38 PM, Eric V. Smith rep...@bugs.python.orgwrote:
Eric V. Smith added the comment:
So what you're saying is that '{:}' is empty, but '{:10}' is not?
Yes, exactly. The part before the colon says which argument to .format()
to
Eric V. Smith added the comment:
It's not whether a field width is specified that makes it empty or not, it's
where there's anything in the format specifier at all. I'm trying to simplify
the conversation by using format() instead of str.format(), but I'm not
succeeding!
Going back to
Ethan Furman added the comment:
In order to avoid that logic, and cause more format specifiers to result in
str-like behavior, we'll need to implement an __format__ somewhere (IntEnum,
I guess) that makes the int or str decision.
If this is the way format is supposed to work, then I'll add
Eric V. Smith added the comment:
In order to avoid that logic, and cause more format specifiers to result in
str-like behavior, we'll need to implement an __format__ somewhere (IntEnum,
I guess) that makes the int or str decision.
If this is the way format is supposed to work, then I'll
Ethan Furman added the comment:
Drat. IntEnum is supposed to be a drop-in replacement for int. I guess I'll
have to consider more than just the letter
code to decide whether to go with int.__format__ or str.__format__.
--
___
Python tracker
66 matches
Mail list logo
