I think you are too casual in rejecting a standard approach over a custom
clever hack. Making the values enums gives them a standard interface that
goes beyond what you implemented, and just the fact that we can say "these
are IntEnum instances" specifies a lot more of the semantics than pointing
to your class hack.

 It's easy to make a subclass of IntEnum that overrides __repr__ and
__str__. It's also easy enough to override the constructor to make the
values start at 0 (though it would be a nice feature if we could add a
keyword arg to the EnumMeta.__call__() definition to override the start
position). I don't really care that this is more code.

I don't see where there would be a circular dependency; the enum module
doesn't import the re module.

There is one thing that might be less convenient: defining an enum doesn't
automatically make the values globals. But wouldn't the code be better if
the values weren't globals?

Finally. You objected to adding __all__ in the code review. That too,
suggests a somewhat casual attitude. This code may be maintained by your
grandchildren. Give them something future-proof, please.

On Thu, Sep 18, 2014 at 9:14 AM, Serhiy Storchaka <report@bugs.python.org>
wrote:

>
> Serhiy Storchaka added the comment:
>
> Answering Guido's question about the Enum class. No, it is not appropriate
> here. It has too cumbersome repr (<OPCODES.IN_IGNORE: 16> instead of
> IN_IGNORE). Enum function syntax can't by used because it enumerates values
> from 1. We need three Enum subclasses for three groups of constants, and
> fourth class for MAXREPEAT, and fifth base abstract class. To fit the Enum
> class to our need we need more boilerplate code than to implement minimal
> needed functionality from scratch. And I'm not sure that this will not
> create circular dependency.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22434>
> _______________________________________
>