pycompat.py strategy

[Gregory Szorc]

I'm ~100 patches deep into purging Python 2 from the main repo. (I think
I'll hold off submitting them until 6.1 is out the door.)

Much of the Python 2 deletion work is trivial. But one question that isn't
trivial is what to do with pycompat.py.

Some options:

a) Attempt to delete as much as pycompat.py as possible (leaving only the
pieces needed to abstract over differences in Python 3.5-3.x).
b) Leave the ~complete API provided by pycompat.py and delete pycompat
usage within the repo as much as possible.
c) Leave the ~complete API provided by pycompat.py and still use pycompat
heavily within the repo.

In my series, I'm going with "b" because after deletion of Python 2, many
of the abstractions in Python 2 no longer make much sense and their
presence doesn't accomplish much except confuse people through extra
indirection. Things like pycompat.iteritems() (which is just a proxy to
.items()) don't serve any purpose any more and IMO shouldn't be used.

Other parts of pycompat are harder to delete. e.g. strkwargs() and
byteskwargs() are used pretty heavily and form an API contract. So I
anticipate we'll be living with them for a while.

As much as I would like to delete APIs from pycompat.py entirely, I think
we should keep them around so extensions have a stable API to manage the
Python 2 -> 3 and <=6.1 to >6.1 migrations. However, I think we should
establish a schedule for marking them as deprecated and deleting them. This
schedule should be independent of their usage within the repo, as the two
decisions are separate.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20220221/6a8aa890/attachment.html>