r/Python Pythonista 6d ago

News The Move to Python 3 Begins!

As someone who spent decades in the mainframe community, I find it ... humorous ... that there are legacy Python2 code bases that are only just (or have yet to consider!) moving to Python3.

https://www.eveonline.com/news/view/the-move-to-python-3-begins

301 Upvotes

106 comments sorted by

View all comments

72

u/bmrobin 6d ago

depending on the codebase, 2->3 is no joke and has so much risk

71

u/ApplicationOk3587 6d ago

What do you mean they can just throw fable at it and add "make no mistakes"

25

u/SheriffRoscoe Pythonista 6d ago

"And while you're at it, hack our competitors and crash their servers."

30

u/ZCEyPFOYr0MWyHDQJZO4 6d ago

tbf the best LLMs are finally quite capable of porting code.

38

u/The_Northern_Light 6d ago

Usually I agree with you but apparently they’re running a custom internal version of Python 2 with bespoke async handling.

Porting that seems a bit more exciting.

2

u/case_O_The_Mondays 6d ago

Yeah, this migration will have to be done in stages: <2.7 -> 2.7, then 2.7 -> 3.x.

I had forgotten about the division issues until I read this article. I worked on a finance app that used some python, and that was my baptism into python 2.6. Fun times!

5

u/Deto 6d ago

yeah, what used to be a pain in the ass (because it's tedious) can be offloaded now. I'd still say a lot of companies won't bother because if it's working, why update it? (sure, security, but if those instances aren't facing the internet there's low risk).

1

u/pag07 6d ago

At least during the last 2 years time and time again we can read articles about how large Mainframe Migrations still keep failing.

The amount of success stories is very small.

1

u/fallenreaper 6d ago

Every function needs 10x the lines of slop to verify.

-4

u/dogfish182 6d ago

Fable is crazy good though

-9

u/daidoji70 6d ago

What do you mean? I migrated about 3-4 python projects from 2->3 about a decade ago and other than pandas and pandas related projects it was a breeze. Run 2to3.py and review. Barely a hiccup.

23

u/bmrobin 6d ago

i'm glad your experience was barely a hiccup. among several pitfalls i recall,

unicode being the default representation for strings, and having to migrate code that manually called `decode/encode` on text.

integer division of `1 / 3 == 0` is true in py2, and py3 it's not because it returns the float result. that had cascading effects throughout multiple layers of our stack.

6

u/Dr_Quacksworth 6d ago

I ran into very similar issues using 2to3.py

-9

u/daidoji70 6d ago

The first one should be fairly straightforward with 2to3, the second one I can def see being more difficult for sure.

13

u/jayroger 6d ago

The first one is anything but straightforward. 2to3 is no help for str/unicode -> bytes/str. Most problems only manifest themselves at runtime. But it was worth it, the after situation is so much better.

16

u/a__nice__tnetennba 6d ago

And how many of your projects were 2.4 million lines of code?

5

u/bmrobin 6d ago

not to mention having unit test cases that covered the minutiae that came with that major upgrade

2

u/case_O_The_Mondays 6d ago

You only have test cases if you’re lucky.

-3

u/daidoji70 6d ago

What does that matter? 2to3.py issues should be distributed evenly throughout a codebase. The issue per number of lines should remain roughly the same per project unless there are pathological cases.

Not sure why I'm getting down voted for asking a question and getting this type of response. Lines of code is always the worst metric in software engineering even when talking about migrations. It tells us literally nothing about how easy or difficult an effort should be.

13

u/Dr_Quacksworth 6d ago

Umm if you have 10x lines of code to review then you have to spend 10x time reading those lines of code.  For a legacy system, you have to pretty much review everything to make sure nothing breaks.

2to3.py doesn't solve everything.  In py2 you might be using floor dividion and then suddenly in py3 you are doing true division.  That sort of change can have major implications.

Not to mention dependency hell...

-7

u/daidoji70 6d ago

Yeah, apparently everyone was out there doing floor division.

1

u/a__nice__tnetennba 6d ago edited 6d ago

I wasn't sure if you were being sarcastic at first so I almost didn't reply to the first comment. Thanks for clearing it up. Although, I think some people still aren't getting the joke, which explains the down votes.

5

u/N-E-S-W 6d ago

Apparently you never read a byte from a file or device and had to interpret it as a string? The 2to3 stuff is trivial, mechanical refactoring.

Unicode strings and encodings required deep introspection of the meaning of data, often exposing silent preexisting bugs in string handling that could no longer be ignored.

2

u/AxeLond 6d ago

Some unrelated code or unittest seemingly depending on python2 unordered dict vs python3 insertion order dict is also fun problem to have.

-2

u/daidoji70 6d ago

oh the meaning, thanks for your input.

2

u/assumptionkrebs1990 6d ago

2to3 has been decrept (depending deprecation 3.9/fully decrept 3.11) and removed (since 3.13) for a while now.

1

u/SheriffRoscoe Pythonista 6d ago

And yet, 2to3 is part of their plan.

1

u/daidoji70 6d ago

Def, but so was the support for python2 and that didn't stop these companies apparently.

-9

u/totheendandbackagain 6d ago

True, but LLMs make conversion trivially simple.

Good luck to the migrators. Best get off zOS at the same time too.

6

u/Dr_Quacksworth 6d ago

LLMs are great for refactoring, but I'm going to be reviewing every changed line before merging in AND running tests.  Not trivial for certain critical services.