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 ethan.furman
Recipients barry, eli.bendersky, eric.smith, ethan.furman, serhiy.storchaka
Date 2013-08-16.00:20:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <520D704D.2070808@stoneleaf.us>
In-reply-to <520D6B70.5080500@trueblade.com>
Content
> 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)?  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?

Yes.

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

Which is why I suggest concentrating on what defines an "empty" format string.  In this case "empty" means what can we 
put in the format spec and still get string treatment.

> Consider if the mix-in type is datetime: it's format strings don't end
> in a the set of characters you list.

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.
History
Date User Action Args
2013-08-16 00:20:34ethan.furmansetrecipients: + ethan.furman, barry, eric.smith, eli.bendersky, serhiy.storchaka
2013-08-16 00:20:34ethan.furmanlinkissue18738 messages
2013-08-16 00:20:32ethan.furmancreate