First, another note I would like to point out: this is much nicer to write
within namedtuple than as a wrapper function because it is trivial to use
the existing rename logic when needed, as seen in the diff I provided. I
suppose I could write a wrapper which calls namedtuple and then changes the
class name after creation but that just feels icky. The only other
alternatives would be to duplicate the rename logic or have the wrapper not
work with rename.

By way of response to R. David Murray: Every use case, of everything, is
specialized. Another way of thinking of what I'm suggesting is that I would
like to make providing a typename optional, and have the library do its
best based on the other information provided in the call to namedtuple.
This pretty well has to mean mashing the fieldnames together in some way
because no other information about the contents of the namedtuple is
provided. So I think this is a very natural feature: what else could it
possibly mean to pass None for the typename?

If for a particular application some other more meaningful auto-generated
name is needed, that could still be provided to namedtuple(). For example,
an ORM that uses the underlying table name.

In response to other suggestions, I don't see how one can prefer "_" all
over the place in debugging output to a string that identifies the
fieldnames involved. Or really, just the option of having a string that
identifies the fieldnames: I'm not forcing anyone to stop passing '_'.

To INADA Naoki: thanks for pointing that out. I agree that in the subclass
case it no longer matters what typename is used for the namedtuple itself.
But isn't that a good reason to allow skipping the parameter, or (since you
can't just skip positional parameters) passing an explicit None?

On 1 August 2017 at 11:02, R. David Murray <report@bugs.python.org> wrote:

>
> R. David Murray added the comment:
>
> I think the "vaguely" pretty much says it, and you are the at least the
> first person who has *requested* it :)
>
> This is one of those cost-versus-benefit calculations.  It is a
> specialized use case, and in other specialized use cases the "automatically
> generated" name that makes the most sense is likely to be something
> different than an amalgamation of the field names.
>
> So I vote -0.5.  I don't think even the small complication of the existing
> code is worth it, but I'm not strongly opposed.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue31085>
> _______________________________________
>