bug or feature in enum34 py2.7 backport?

[Mark Summerfield]

Hi,

Here are two programs both executed with Python 2.7 with the enum34 backport and their output. Is this a bug or intended behavior? (It may well be intended to help ensure that the class name is ASCII for Python 2; but maybe it would be nicer to check a unicode to see if it is ASCII and if so, use it, and otherwise raise a more helpful exception?)

# t1.py
from __future__ import print_function
import enum
print(enum.version)
A = enum.Enum("A", "b c")
print(A.b, A.c)

$ python2 t1.py 
(1, 0, 3)
A.b A.c

# t2.py
from __future__ import print_function
from __future__ import unicode_literals
import enum
print(enum.version)
A = enum.Enum("A", "b c")
print(A.b, A.c)

$ python2 t2.py 
(1, 0, 3)
Traceback (most recent call last):
  File "t2.py", line 5, in <module>
    A = enum.Enum("A", "b c")
  File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 326, in __call__
    return cls._create_(value, names, module=module, type=type)
  File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 434, in _create_
    enum_class = metacls.__new__(metacls, class_name, bases, classdict)
  File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 188, in __new__
    enum_class = super(EnumMeta, metacls).__new__(metacls, cls, bases, classdict)
TypeError: type() argument 1 must be string, not unicode