r/Python • u/SheriffRoscoe 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

302 Upvotes

90% Upvoted

106 comments sorted by

View all comments

70

u/bmrobin 6d ago

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

-8

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.

22

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.

5

u/Dr_Quacksworth 6d ago

I ran into very similar issues using 2to3.py

-6

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.

11

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.

-4

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.

11

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...

-6

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.

3

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.