On 2025-02-03 23:31, Hal Murray via devel wrote:
Did you see my comment about how dropping Python 2 before getting rid of
the polyXXX wrapers is dangerous, because removing the wrappers without
properly fixing the underlying code is more likely to break Python 3 than
Python 2?
I'm concerned that we might be talking past each other here. I'm not
sure what you think "dropping Python 2" and "getting rid of the polyXXX
wrappers" means.
Based on my idea of what those things mean, it has to be in the other
order. We have to drop Python 2 before we can get rid of the polyXXX
wrappers, as the whole point of the polyXXX wrappers is to support both
Python 2 and Python 3 at the same time. I don't see how we can
reasonably get rid of those wrappers while still supporting both Python
2 and Python 3.
Are you thinking that I think we can just s/polystr/str/ and call it a
day on Python 3? I know we can't do that.
Yes, but I don't know enough about Python to know what it really means. I
was assuming tha would be part of getting rid of Python 2.
To me "dropping Python 2" first and foremost means making the decision
that Python 2 is no longer supported by the codebase.
To me, it also _implies_ some changes up front: We will relatively
quickly want to remove any CI for Python 2, as future changes will break
it. We should probably adjust the Python version check in waf right away
too.
Of course, if we decide to give one release's warning, then it goes:
decision, update NEWS, release, then and only then start changing things
like waf checks, CI, etc.
Everything else is just _unblocked_ and we can make the changes as
developer time permits. One of those changes is "getting rid of the
polyXXX wrappers".
To me "getting rid of the polyXXX wrappers" would be something like this:
1. The poly code has a big if statement that amounts to:
if Python 2:
foo
else:
bar
Once we no longer care about Python 2, we can drop the if statement,
keeping only the else arm, and dedent it. Everything on Python 3 works
exactly as it always has. <git commit>
2. Some of the poly code is unused. For example, nothing uses polychr().
Remove such things. <git commit>
3. Some of the poly code is just directly mapped, e.g. "polyinput =
input". In the callers, replace e.g. ntp.poly.polyinput() with input(),
adjusting imports as appropriate. <git commit>
4. That leaves the poly code that actually does something on Python 3.
Work function-by-function, caller-by-caller, on the rest. This is the
"hard" part (the actual work). Some of this can probably be done as
independent commits. Some of it, however, may be intertwined, e.g. with
the output wrapper setup.
--
Richard
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
