pycompat.py strategy

[Pierre-Yves David]

On 2/21/22 19:47, Gregory Szorc wrote:
> 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?


Keeping the pycompat module around for some versions is probably the 
simplest from as extension point of view. So (b) seems like the best 
option to me.


-- 
Pierre-Yves David