On 08/20/2013 11:15 PM, Ethan Furman wrote:
On 08/14/2013 09:27 PM, 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
On 08/14/2013 09:27 PM, 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 type was the pretty
str and repr, I don't s
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 mi
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.forma
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
> 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
> cod
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:
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 maili
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
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
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 r
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
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 believ
On 8/14/2013 9:27 PM, Nick Coghlan wrote:
I think Eric is overinterpreting the spec, there. While that
particular sentence requires that the empty format string will be
equivalent to a plain str() operation for builtin types, it is only a
recommendation for other types. For enums, I believe t
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 (s
From http://bugs.python.org/issue18738:
Ethan Furman commented:
--> class Test(enum.IntEnum):
... one = 1
... two = 2
...
--> '{}'.format(Test.one)
'Test.one'
--> '{:d}'.format(Test.one)
'1'
--> '{:}'.format(Test.one)
'Test.one'
--> '{:10}'.format(Test.one)
' 1'
Eric V. Smith c
16 matches
Mail list logo
