bug or feature in enum34 py2.7 backport?

[random832 at fastmail.us]

On Wed, Nov 26, 2014, at 09:40, Chris Angelico wrote:
> I'd say that's a limitation, not a bug. A lot of stuff in Python 2
> depends on identifiers being ASCII-only byte strings, including -
> apparently - parts of the core code.

But why shouldn't the type constructor do the conversion (and any
validation of being ASCII-only) when parsing the arguments? The root
cause seems to be that it parses its arguments with "SO!O!:type"
(typeobject.c, line 2097). Does anyone know what problems would be
caused, in general, by having S do a conversion if provided with a
unicode object?

It seems like if it is a bug to reject long where int is accepted, it
should be likewise considered a bug to reject ASCII-only unicode where
str is accepted.