pycompat.py strategy
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? ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: pycompat.py strategy
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.) Thanks, we indeed need the focus on the current release, I'll be happy to review them after the freeze. 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? I agree that we really shouldn't delete pycompat stuff during the 6.2 cycle, and I'm not entirely convinced that deleting any of it is worth it at any point. Keeping around the module shouldn't impact core in the long run and can avoid breakage for external code for the low price of some small amount of dead code. Raphaël ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: pycompat.py strategy
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). Joerg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: pycompat.py strategy
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? :) Joerg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: pycompat.py strategy
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. Joerg ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: pycompat.py strategy
On Tue, Mar 1, 2022 at 5:08 AM Joerg Sonnenberger 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. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: pycompat.py strategy
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 ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
