This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.smith
Recipients barry, eli.bendersky, eric.smith, ethan.furman, serhiy.storchaka
Date 2013-08-15.23:59:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <520D6B70.5080500@trueblade.com>
In-reply-to <520D5FA3.8000205@stoneleaf.us>
Content
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).
> 
> 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)?  I'm thinking "<^>01234566789".  Anything else 
> ("+", all letter codes, etc.) gets the normal (host-type) treatment.

Is the goal of this approach to implement __format__ in Enum instead of
IntEnum?

But you can't do this in general, because in the place you implement
__format__ you must understand the mix-in type's format strings.
Consider if the mix-in type is datetime: it's format strings don't end
in a the set of characters you list. So I think you have to implement
__format__ on each derived-from-Enum type so you can make the best
decisions there.

I think we want to have the most possible interpretations give a str
output, and only use the base type if that's explicitly asked for. As
Eli says, that's one of the main reasons IntEnum exists in the first
place. Hence my approach for IntEnum.__format__.
History
Date User Action Args
2013-08-15 23:59:52eric.smithsetrecipients: + eric.smith, barry, eli.bendersky, ethan.furman, serhiy.storchaka
2013-08-15 23:59:52eric.smithlinkissue18738 messages
2013-08-15 23:59:52eric.smithcreate