Catching up

[Richard Laager]

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