Eric V. Smith added the comment:
>
> this gives the (to me) surprising results of:
>
>>>> format(S.a)
> 'S.a'
>>>> format(S.a, '10')
> 'S.a'
>>>> format(S.a, '10s')
> 'A'

that is surprising: if a __format__ is defined in the Enum class chain 
then it should be used instead of the default.  I'll fix that (I treat 
__new__, __repr__, __getnewargs__, and maybe one other the same way).

> Also, the patch give this:
>
>>>> class E(IntEnum):
> ...   one = 1
> ...   two = 2
> ...
>>>> format(E.one)
> 'E.one'
>>>> format(E.one, 's')
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/home/eric/local/python/cpython/Lib/enum.py", line 463, in __format__
>      return obj.__format__(val, format_spec)
> ValueError: Unknown format code 's' for object of type 'int'
>
> I can't format it using the 's' presentation type, despite the fact it looks like a string. I think you need to add 's' to your _remove_plain_format_chars.

Well, they are Enums, not strings.  And if I add 's' to the remove, then 
a str-derived enum would not pass through to the value correctly.

> And consider this valid (but arguably pathological) code:
>
>>>> format(datetime.datetime.now(), '10')
> '10'
>
> Despite this being a valid datetime format spec, your code would consider it a str spec.

Sounds like the way forward is to specify in the docs how the default 
Enum __format__ behaves (basically honors width and justification 
settings to yield the name, anything else passes through to the Enum 
member) along with advice matching that for __str__ and __repr__: if you 
want something different, write your own method. ;)

And I learned something else:  the format mini-language is really in two 
parts; the first part is selecting the object to be printed ({} or {3} 
or {some_name} or {other.name} etc., etc.) and the second part is the 
format spec for the object selected.  The kicker is that each object can 
specify what it knows about.  So float's treat 'f' as float, but 
something else might treat 'f' as fixed.