I've threatened@gpshead with this change a few times, so I'll tag him (not knowing what exactly happens to random PRs againstcpython)

Please open an issue for such change and add a NEWS entry so that this change is announced (it affects public classes since they inherit from those private ones). I didn't look at what you did though so I don't know if this change will be accepted. But the workflow should be: issue -> discussion -> PR (in that order, possibly skipping discussion if there is a clear issue). TiA.

I assume it uses ._replace so that it doesn't preclude folks from using namedtuple with a field named replace

Yes.

(Then there's the issue with linters complaining about usage of using a method that starts with an underscore, but that's not my motivation so I'll just point it out and move on)

AFAIK, pylint doesn't have this issue because it treats such special methods for namedtuples as public (and theyare publicly documented).

(A)

One could ask for this as a more general feature of namedtuple...https://github.com/python/cpython/compare/main...gpshead:cpython:namedtuple-with_replace_method?expand=1 would do that.

Butthat begs the question why._source and._field_defaults don't get the same treatment if added to enable.replace to officially exist?

SO...

(B)

I wholly agree that APIs suggesting actually using ._ prefixed things are cursed. But the other bigger picture is that namedtuple was often a convenient useful mistake of an API. They got used nicely in places where the APIs used to be... actual tuples without names. So they're a transition. Better than before!But decade(s) later, we all look at these and question why they even behave like tuples. Especially when we need to add more fields and cannot because it breaks existing code's fixedun, pack, ing = assignment(). So an annoying to craft but proper API compatible replacement type winds up being desired and recreated: An actual object (non-frozen dataclass like I suppose) with .fields as attributes. Thatalso behaves as a sequence for indexing and unpacking purposes for compatibility's sake impacting the older fields that line up with those indices.

If we want a properly named method, we should probably adopt a common form of those instead of modifying namedtuple or hacking this into some places and not others that use namedtuple in an inconsistent manner.