Rewrite of the namedtuple implementation to avoid the use of exec for
class generation.  The new code uses a custom class dictionary and the
builtin type to create new classes dynamically.

Have you run benchmarks of both versions? It seems the benefit of the
original version is that it's faster, thanks to hardcoding critical methods.

The current version is clear and maintainable. There is nothing unholy
about using exec. Earlier versions used other approaches and they
proved unnecessarily complex and had unexpected problems. It is a key
feature for named tuples that they are exactly equivalent to a
hand-written class.

I appreciate your effort but am rejecting it flat-out.

Yes, exec is unholy:)

For embedding Python into a console game we have removed the python compiler. exec and eval don't work. This saves space and is also a security feature. I had to modify the collections module so that namedtuple() just returns tuple. Fortunately, no part of the standard library that uses namedtuple actually uses the actual names, everyone just uses it as a tuple. So that approach works.

Another problem with the Eval approach is code duplication.

A third could arguably be that there is no namedtuple base class.

Now, replacing namedtuples with tuples works in the standardlib _currentlyt_, but I'm happy to have found an alternative implementation, for future safety. I only wish it were not hidden away as a diff in a feature request.