Re-export ._replace as .replace in urllib.parse result types

[thejcannon]

I do Python interviewing, and part of one of our interviews has folks parsing URLs.

I've noticed people gloss over the ._replace at the end of the examples in https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlparse and I'm somewhat convinced that's due to the fact that subconsciously PEP 8 (and beyond) has trained folks to assume leading underscore is not "public" ( a good convention).

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

But for concrete namedtuple subclasses which are known not to have a replace field, it'd be nice if the callers could just use .replace like all the other "normal" classes.

(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)

(I also don't want this to devolve into a conversation about "ok but what about ". Perfect is the enemy og good)

[thejcannon]

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

[picnixz]

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 they are publicly documented).

[gpshead]

(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.

But that 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 fixed un, 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. That also 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.