pycompat.py strategy

[Gregory Szorc]

On Tue, Mar 1, 2022 at 5:08 AM Joerg Sonnenberger <joerg at bec.de> wrote:

> Am Tue, Mar 01, 2022 at 11:20:41AM +0100 schrieb Raphaël Gomès:
> >
> > On 2/22/22 23:06, Joerg Sonnenberger wrote:
> > > Am Mon, Feb 21, 2022 at 11:47:36AM -0700 schrieb Gregory Szorc:
> > > > 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.
> > > Personally, I'd prefer to start with (c) and gradually go to (b).
> > Care to elaborate? :)
>
> We can start just nuking the non-py3 case in pycompat and then slowly
> inline it in the rest of the tree. Ideally using a tool for the
> mechnical part of it.
>

I think we're in general agreement here.

I already have some patches authored to nuke the Python 2 code paths in
pycompat.py as well as to start undoing some undesired patterns, such as
pycompat.iteritems(x) -> .iteritems(x). I'll try to get them up on
Phabricator tonight.

FWIW Augie seems inclined to write the ceremonial patch to setup.py.
Hopefully that will appear in <24 hours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20220301/ca993d33/attachment-0002.html>