OK, so it's pretty clear this is heading towards a rejection, but I can't
help but respond to your points:

On 2 August 2017 at 01:12, Raymond Hettinger <report@bugs.python.org> wrote:

* This would be a potentially  confusing addition to the API.
>

I'm giving a natural meaning to providing a None where it is not permitted
now. The meaning is to provide a reasonable value for the missing
parameter. How could that be confusing? Also it's completely ignorable -
people don't have to pass None and get the auto-generated typename if they
don't want to.

> * It may also encourage bad practices that we don't want to see in real
> code.
>

What bad practices? There are lots of times when providing an explicit name
is a waste of effort. This provides a simple way of telling the library to
figure it out. Aren't there supposedly just two hard things in computer
science? Naming things, and cache invalidation. An opportunity to avoid
naming things that don't need to be specifically named is something worth
taking.

> * We want to be able to search for the namedtuple definition, want to have
> a meaningful repr, and want pickling to be easy.
>

You mean by searching for the typename in the source code? In my primary
usecase, the typename is computed regardless, so it doesn't appear in the
source code and can't be searched for. The other suggestion which appeared
at one point was passing "_" as the typename. This is going to be somewhat
challenging to search for also.

As to the meaningful repr, that is why I want auto-generation of the
typename. This is not for uses like this:

MyType = namedtuple ('MyType', ['a', 'b', 'c'])

It is for ones more like this:

rowtype = namedtuple (None, row_headings)

Or as it currently has to be:

rowtype = namedtuple ('rowtype', row_headings)

(leading to all the rowtypes being the same name, so less meaningful)

Or:

rowtype = namedtuple ('__'.join (row_headings), row_headings)

(which repeats the irrelevant-in-its-details computation wherever it is
needed and doesn't support rename=True, unless a more complicated
computation that duplicates code inside of namedtuple() is repeated)

Finally I'm not clear on how pickling is made more difficult by having
namedtuple() generate a typename. The created type still has a typename.
But I'm interested - this is the only point I don't think I understand.

* This doesn't have to be shoe-horned into the namedtuple API.  If an
> actual need did arise, it is trivial to write a wrapper that specifies
> whatever auto-naming logic happens to make sense for a particular
> application:
>
>     >>> from collections import namedtuple
>     >>> def auto_namedtuple(*attrnames, **kwargs):
>             typename = '_'.join(attrnames)
>             return namedtuple(typename, attrnames, **kwargs)
>
>     >>> NT = auto_namedtuple('name', 'rank', 'serial')
>     >>> print(NT.__doc__)
>     name_rank_serial(name, rank, serial)

Your code will not work if rename=True is needed. I don't want to repeat
the rename logic as doing so is a code smell.

In short, I'm disappointed. I'm not surprised to make a suggestion, and
have people point out problems. For example, my original proposal ignored
the difficulties of creating the C implementation, and the issue of
circular imports, and I very much appreciated those criticisms. But I am
disappointed at the quality of the objections to these modified proposals.