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 eli.bendersky
Recipients barry, eli.bendersky, eric.smith, ethan.furman, serhiy.storchaka
Date 2013-08-14.19:12:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAF-Rda_T8MKaFwbJd2CWHNO4VOTXv99vF8C6pCgv2V0EAuVgdA@mail.gmail.com>
In-reply-to <520BD569.8090503@stoneleaf.us>
Content
On Wed, Aug 14, 2013 at 12:07 PM, Ethan Furman <report@bugs.python.org>wrote:

>
> 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 codes that specifically call for a numeric representation
> should give that numeric representation (format is
> good here, % is not).
>
> > 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 think for format we should treat IntEnums as ints unless the s or r
> codes are specifically used.
>

As I wrote above, I rather see it differently. The original intent of Enums
was to have string representation in most cases. So this should be the
default, since most of the time this is what the user wants. No one really
passes explicit s/r codes. In the minority, specialized cases, where the
user wants to force int-like formatting, then the number should be given
and not the member name. This would also be consistent with non-decimal
formatting options like %x and the .format equivalent.
History
Date User Action Args
2013-08-14 19:12:14eli.benderskysetrecipients: + eli.bendersky, barry, eric.smith, ethan.furman, serhiy.storchaka
2013-08-14 19:12:14eli.benderskylinkissue18738 messages
2013-08-14 19:12:13eli.benderskycreate