Not if one of the attributes is something that cannot be part of a typename:

>>> fields = ['def', '-']

>>> namedtuple ('test', fields, rename=True).__doc__

'test(_0, _1)'

>>> namedtuple ('__'.join (fields), fields, rename=True).__doc__

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/collections.py",
line 339, in namedtuple

    'alphanumeric characters and underscores: %r' % name)

ValueError: Type names and field names can only contain alphanumeric
characters and underscores: 'def_-'

>>>

Which I admit is a weird thing to be doing, but duplicating attribute names
or trying to use a keyword as an attribute name (or anything else that
requires rename=True) is also weird.

Also it's far from clear that the pre-renaming field names are what is
wanted in the auto-generated typename. If I was actually using attribute
names that required renaming I would want the auto-generated typename to
match the renamed attributes. The original fieldnames play no part in the
operation of the namedtuple class or its instances once it has been
created: only the renamed fieldnames even remain reachable from the
namedtuple object.

Anyway I think I'm probably out at this point. I think Python development
is not a good cultural fit for me, based on this discussion. Which is
weird, since I love working in Python. I even like the whitespace
indentation, although admittedly not quite as much as I thought I would
before I tried it. I hugely enjoy the expressiveness of the language
features, combined with the small but useful set of immediately-available
library functions, together with the multitude of importable standard
modules backing it all up. But I should have known when functools.compose
(which ought to be almost the first thing in any sort of "functional
programming" library) was rejected that I should stay away from attempting
to get involved in the enhancement side of things.