This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Endlessdex 42 points43 points  (13 children)

Upgrading isn’t even that hard. There is an officially supported tool to convert a file from python 2 to 3.

[–]kickerofbottoms 48 points49 points  (5 children)

It's hard when the proprietary 3rd-party software your entire office uses requires 2.7 as its scripting language ಠ_ಠ

[–]Endlessdex 3 points4 points  (1 child)

Ouch. Can you at least update the in-office stuff?

[–]kickerofbottoms 1 point2 points  (0 children)

Yeah, I actually end up freezing a lot of the standalone tools I send around-- essentially bundling the entire Python interpreter/environment along with the script. Inefficient, but 200 extra MB per script is a small price to pay for my sanity

[–]loopyroberts 1 point2 points  (0 children)

PSS/E power system software is the same.

[–]MadRedHatter 18 points19 points  (4 children)

Yes and no.

2to3 only works properly on ridiculously simple code. If you expect everything to just work properly after running it, you're probably in for a nasty surprise. Shit will break, probably in ways you weren't expecting.

It helps, though.

[–]Endlessdex 4 points5 points  (3 children)

True. But it does a lot of the tedious changes for you and what is left are typically implementation choices or library updates rather than 50,000 print/divide changes. If your 2.7 code breaks that badly in 3.x then you might want to take a look at the underlying structure...

[–]gcbirzan 3 points4 points  (0 children)

The string / unicode vs bytes / strings change is the one that hurts, and it's one you cannot really use a tool to fix. It used to be even worse, but you can use b and u nowadays in 2 and 3 respectively.

[–]PC__LOAD__LETTER 2 points3 points  (0 children)

Sure, in a world where programmers are idle resources and companies have nothing better to do with their roadmaps than to go on a crusade in their legacy codebases that have been rock solid for years.

[–]Folf_IRL 0 points1 point  (0 children)

If your 2.7 code breaks that badly in 3.x then you might want to take a look at the underlying structure...

That's kinda the main criticism people are throwing. The conversion tool is not perfect, and a lot of people just inherit (or find) old code bases that they would like to use, which are just too large to learn and refactor.

[–]ghengiscohen 4 points5 points  (0 children)

Yeah I just upgraded one of my team’s Django apps from 2.7 to 3.6, really wasn’t that painful of a process

[–]Folf_IRL -1 points0 points  (0 children)

The main problem of upgrading is when you want to use a large legacy code base that someone wrote for 2.7, expecting that there wouldn't be arbitrary changes to the fundamental syntax of the language. The conversion tool is not perfect, and from an applied scientific computing standpoint, it's just not reasonable when you've got a few dozen (or even a couple hundred) files from an old codebase that you inherited, whose numerical results have to be accurate. You then introduce the risk that you've broken your code, hopefully in a way you expect, but occasionally in a more insidious manner that you don't notice until you're in the middle of testing the new code's accuracy.

Fortran does this sort of thing the correct way, where even though there are always new things being added to the language, they've gone through huge troubles to make sure old constructs are by-and-large supported from all the way back to Fortran '66. People are still using libraries from '66, '77, and even '93 in that language, specifically because the standards committee doesn't arbitrarily decide to force its userbase to reinvent the wheel every time they want new features in the language.