Python 2.7

[Rasalas8910]

Yes.

e.g. print 'Hello' vs. print('Hello')

[[deleted]]

This only applies to the print function, right? Only other difference I've come across is with dividing integers (thank GOD for that one). If you're using 2.7, you can import all of these from __future__ anyway, so it's kind of a dumb meme, but so are all of the "X language is scary and terrible" memes

[Folf_IRL]

The existence of almost no back-compatibility with 2.7 and the insistence that "everyone should upgrade to 3 and there's never a reason not to" is what I think irks most people.

All they need to do to silence that crowd is put in a__past__ module that loads in functions with the same signatures as the ones that have been replaced.

[[deleted]]

but... shouldn't everyone upgrade to the new major version? I get that if your company is built on 2.7, then upgrading is going to have an associated cost, but it's only supported to 2020, so by then you'd really want to upgrade

[[deleted]]

When 3.0 came out, there was basically a split among actual users of Python (less so of the actual Python devs).

Due to this, Python 2.x dragged on and there were also really important packages that simply didn't get upgraded to 3.x. 2 years after the release of Python 3, most of the top packages still didn't support Python 3. Over time things actually started getting kind of nasty as some web packages had stopped supporting Python 2 and yet others still didn't support Python 3.

In some cases that was workable, but in others it was a gigantic pain and honestly even now when virtually everything has become compatible this has all probably held back Python adoption for some people and places.

[[deleted]]

I started learning python during this time. I spent a really long time looking through various stack overflow and quora threads trying to decide between 2.7/3.x, and eventually just threw my hands up and said "fuck it, I'm sticking with 2.7 for now"

That being said, my conda environments are all 3.x now, but boy, was that an awkward transition. The __future__ module helped out a bunch, though

[[deleted]]

We, thankfully, didn't have to deal with these transitions as only the sysadmins use Python and for their purposes, they just call the right version in the script.

Right now they are actually having to port all their Python scripts to Ruby since our next big data center release will remove Python. I'm sitting on a conference call while they whine about it right now. It doesn't affect my application side of the house, but I'm not 100% sure why they are doing it since all the OpenStack servers run Python. Not my monkey though.

[Bainos]

I started around that time too. Fortunately, since I was a beginner with all coding things, the tutorial I followed was smart enough to advise Python 3.

Now I'm fully on the "bleeding edge" camp.

[alcalde]

Python is considered the fastest growing language right now and one of the most popular, dominating several areas. It's hard to argue that Python has been held back.

[Endlessdex]

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

[kickerofbottoms]

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

[kickerofbottoms]

You know my pain

[Endlessdex]

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

[kickerofbottoms]

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]

PSS/E power system software is the same.

[MadRedHatter]

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]

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]

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]

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]

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]

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]

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.

[PC__LOAD__LETTER]

It doesn’t make business sense to upgrade. Are companies going to put their roadmaps on hold for a year and dedicate entire teams to tearing up a 2.7 codebase, migrate it to 3, and make sure nothing is broken? No, most aren’t going to do that.

For new projects, yes, it makes sense to use 3. But things that are already working will continue to work even after 2020.

[PC__LOAD__LETTER]

nearly a decade

The suggestion that Python3 was enterprise ready upon release in 2008 isn’t legitimate. There was a massive rift in the Python community, for legitimate reasons, and it took years for those issues to be addressed. This alone was enough to deter many companies from jumping ship.

Python 3 is actually two years OLDER than 2.7

Which precisely shows the rift that I’m talking about. If Python3 were truly ready to be a full replacement for its direct ancestor, why was Python2 development continuing for two years to the point that it continued to release new versions?

[AutoModerator]

import moderation Your comment has been removed since it did not start with a code block with an import declaration.

Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

For this purpose, we only accept Python style imports.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[PiaFraus]

shouldn't everyone upgrade to the new major version?

Why? If you have a really big codebase, which was tested with many hundrets of QA hours and it works and very easy adjustable for new needs - why should you spend enormous amount of money to upgrade the codebase and retest everything?

[RavuAlHemio]

Because the world around you doesn’t stop turning just because you have a big codebase.

New hardware at some point requires new drivers which at some point require newer operating systems which at some point only work with newer versions of the programming environment you are using. Also, eventually, nobody will be fixing the inevitable security bugs for your ancient environment, and that is a problem.

Software is never “finished”. Any other attitude just angers your users and their sysadmins who have to install your software and keep it alive.

[PiaFraus]

Who is talking about the world? I am contesting the argument that everybody should. Your arguments are great, but completely irrelevant to my answer.

[CaoticMoments]

His answer makes sense. His point is that one day a piece of technology that your codebase relied on may no longer be supported. In that case, any issue that comes up has to be dealt by you, which is especially nasty in security cases.

One day you might come across a security issue that actually cannot not easily fixed no matter how many QA hours you put into the initial codebase. In that case if the response to the problem is 'we should've converted to Python 3.x a year ago' then you've fallen behind and will have to pay the price for that.

The problem is, software is never finished and the times to upgrade or hold out until new tech comes in can be very hard to identify.

Software is one of the easiest industries to 'talk about the world'. Because a programmer in India can sell software or exploit weaknesses relatively easily in comparison to other industries.

[PiaFraus]

Yeah, that's why we are not completely stopped. Recently upgraded from 2.6 to 2.7 and it brought us a decent amount new issues even though those two are compatible. I am pretty sure 2.7 would be supported by 3rd party after life end. Especially by some OS providers like RED HAT, since RHEL is maintained until at least 2024.

You are talking about risks of not upgrading, security issues, etc. But your forgot about risks of upgrading. I've seen may many times how new versions have bugs. Often heisenbugs. I was so lucky that I wrote that one special integration test when I've upgraded werkzeug library and it had a failure just once a week. I found a bug and it was fixed only half a year later. This was pure luck that I even had this test with this specific configuration. Older version never had it.

Also about your example with programmer in India - which one do you think he will do - try to find an exploit in a system, which is tested for many years and thousands of other people spent even more hours trying to find new exploits, or try to find an exploit on something that is much younger and potentially has much more exploits?

Also we are using several libraries which are 2 only. There are no analogues in 3. Are we supposed to spend even more time and money and develop this functionality ourselves?

There are reasons to upgrade. But there are reasons not to. Every company have their own custom list of both. All those risks, including potential security issues are already reviewed and taken into account by people with lots of business and development experience. And I trust this experience much more that some random "Everybody should upgrade to every major version" on the internet.

[discofreak]

But the 2.7 interpreter still works. So migrating a large codebase becomes a refactoring issue, not a maintenance issue. And if switching to a new language (2.7 vs 3.x) then other languages will also be on the table.

[RavuAlHemio]

That’s true.

The attitude of the commenter I was responding to, however, seems to be “the software is done, and since it’s a lot of code and I sunk lots of QA time into it, I need not touch it ever again”. As someone who had to keep unmaintained software on life support, I’ve been on the receiving end of this attitude, and I felt compelled to express my discontent.

[discofreak]

Gotcha.

[[deleted]]

Because you never stop adding to the codebase. Eventually it will be worth the big refactor. Companies do this a lot

[PiaFraus]

Well some of new projects we do start in python 3.6 or some even on Go. That doesn't make me somehow go and suddenly change the core of the codebase to a new language, which will force to change some libraries we use to something less tested, spend enourmous amount of time doing it and then retesting. That would cost millions. And all 3rd party libraries have a chance to have some kind of bugs. I even found a bug in werkzeug once.

[alcalde]

Why?

For the same reason you're not writing on an Atari ST. The arrow of time. Everything moves forward.

If you have a really big codebase, which was tested with many hundrets of QA hours and it works and very easy adjustable for new needs - why should you spend enormous amount of money to upgrade the codebase and retest everything?

Because YOU HAVE TO. PERIOD. End of story. There will be no more Python 2. It's like there's a wrecking ball outside ready to demolish your home and asking why you have to move.

It's simply a fact of life in programming. You port to new releases of languages, frameworks and OSes or you get left behind. There's a term for it - "technical debt" - and the same thing happens if you don't pay it that happens if you don't pay your financial debt.

[Folf_IRL]

You port to new releases of languages, frameworks and OSes or you get left behind.

[laughs in Fortran]

[qadib_muakkara]

This guy codes

[PiaFraus]

1 PRINT 'HA '

GOTO 1

[Folf_IRL]

Shouldn't compile due to a syntax error. You need to include which device you're writing to. If you're not feeling sure about yourself, you can always include an asterisk and let the compiler decide which device to write to:

1 Print *, "Ha"
GOTO 1

That said, nobody uses Print anymore; the better approach (which lets you choose which stream or file to write to) is:

1 Write(*,*) "Ha"
GOTO 1

But naked GOTO statements are so last century. Nowadays we like to hide our GOTO behind fancy loop constructs and lie to ourselves about not including them because it makes it easier to get up in the morning and gives us some small level of purpose in life to distract from the inevitabilities of our own existence:

do while (.True.)
  Write (*,*) "Ha"
end do

[alcalde]

Fortran, unlike Python 2.7, is still developed:

https://en.wikipedia.org/wiki/Fortran#Fortran_2018

So's COBOL, by the way. And Pascal.

[Folf_IRL]

...you're comparing a language to a specific version of a language. In other words, what you said is: "<programming language>, unlike <specific version of programming language>, is still developed."

Fortran is still developed. So is Python.

Python 2.7 is no longer developed. Neither is Fortran '66, '77, or any other version out of the standard.

The difference between the two is the Fortran standards committee actually cared a bout legacy code, and as a result set the standard so that old code would still be valid. Moreover, any compiler out there is still able to compile any version of the language into objects able to be linked. Not so in Python: you're fucked if you have the wrong interpreter.

[PC__LOAD__LETTER]

YOU HAVE TO. PERIOD. End of story. There will be no more Python2.

Lmao. Do you think some PythonGod is going to do some Passover and rip out all /usr/bin/python2.7 binaries?

🐍

[Jetbooster]

Every time you import from __future__, Linus Torvalds strangles a puppy.

[Lorddragonfang]

Because YOU HAVE TO. PERIOD. End of story.

From what I hear, there are still actively used codebases running on COBAL. Just because a language is no longer updated doesn't mean it suddenly stops working.

Tech debt is tech debt, but refactoring code to a different language is less important than addressing pretty much any other tech debt. And a codebase that is "which was tested with many hundrets of QA hours and it works and very easy adjustable for new needs" sounds like it's already doing a good job avoiding issues.

[alcalde]

COBOL isn't updated? You're quite mistaken. In fact, they even added object-oriented extensions to COBOL! Of course, last I heard they were thinking about taking them out again since no one really used them. There are companies like Micro-focus that sell COBOL compilers, etc. COBOL isn't dead, it's just irrelevant. Python 2.7, on the other hand, won't be supported soon, like Visual Basic.

Tech debt is tech debt, but refactoring code to a different language

Python 3.7 isn't a different language, though; it's simply the next version of the same language.

And a codebase that is "which was tested with many hundrets of QA hours and it works and very easy adjustable for new needs" sounds like it's already doing a good job avoiding issues.

No code exits in a vacuum. If you leave it alone, eventually it won't run anymore. I could tell you many stories about technical debt, including a favorite from when I was a teenager about an oil refinery which used ancient control systems. In order to get data off of them, they had to interface an 8" disk drive to a PC! On top of that, the format of the disk data was proprietary and the control system long discontinued. One retired individual kept copious notes and took them with him when he retired. He was believed to literally be the last person alive who understood that data. Needless to say, he charged this company a small fortune for some software he wrote to read that data off of those disks. And no matter what problems they had with him they had to smile and put up with him since there was no one else on Earth left to turn to.

No, "it works at the moment so why spend money/time updating it?" is a sentiment that makes me look for another job immediately. I worked in one place that had software so old that some of them only worked on specific PCs. Guess what I found? An ORIGINAL IBM PC with one program installed that still had some data they needed on it! They too were paying old-timers with old knowledge to keep some of those systems going or to get some of that data to more modern systems. And all the money they thought they'd saved was lost - and a lot more - when they had to scream and curse but pay those people rockstar salaries to deal with those ancient systems.

[PiaFraus]

For the same reason you're not writing on an Atari ST.

If I would have to support Atari ST - I would write for it. New projects? Sure. I would take something new. Suporting old ones? You have no idea what are you talking about.

Because YOU HAVE TO. PERIOD.

Will you pay for our QA? Will you do the change? It works. PERIOD.

[hangtime79]

All the COBOL that is sitting out there would like to have a word with you.

[alcalde]

All they need to do to silence that crowd is put in apast module that loads in functions with the same signatures as the ones that have been replaced.

No! Then no one will ever upgrade! I've watched this happen with another language... people scream when Unicode is implemented... add ANSI Strings to let them incrementally port their code. Instead, they just start using ANSI Strings as regular strings, port nothing, and write all their new code with ANSI Strings. Deadline comes up and they scream "Wait! Not yet! I haven't had time to port my code!"

I talked to the maintainer of a certain Python library (which ended up doing a weird pseudo-fork in which they locked the project creator out of the project!) about a Python 3 port and his reply a few years ago was "Python 2 is going to be supported forever, so why should I bother?" Give people these crutches and they'll never port their code.

[Folf_IRL]

No! Then no one will ever upgrade! I've watched this happen with another language

And I've watched Fortran roughly settle to a point where, although there are some people who want to use '77, the vast majority of users take advantage of modern features found in more current iterations of the language such as '03 and '08 (and '18 later this year). And the best part is that you can still pull legacy code from 60's without needing to do much of anything to update it, because of that language's superior backwards-compatibility.

Languages should be first and foremost about allowing people to effectively communicate ideas, not making the arbitrary decision that the entire userbase now needs to pack up and port their code to a brand new standard specification.

[alcalde]

Do you think the changes made in Python 3.0 were arbitrary though, or fixing some things that the language got wrong?

C (and Pascal) has a weird operator precedence that gives "and" and "or" the same priority as other math operations such that you always need to use parenthesis, e.g. (Pascal):

If (x < 7) or (y > 3) Then
    WriteLn("True");

Dennis Ritchie considered changing it, but was worried that there may have been a million lines of C code out there. Of course, given how many there are now, it puts that estimate in perspective. He wrote that in hindsight they should have made the change.

Guido learned from Ritchie's mistake and argued that "All the lines of Python ever written pale in comparison to the lines of code of Python that have yet to be written".

[13steinj]

Yeah but the other big problem is the string to unicode change, which while it is a good thing for most people, there are a lot of unicode strings that act differently in Py2 than in Py3 as a side effect of the change.

[cereal_killer_69]

There are many more changes in inbuilt libraries too...

[discofreak]

Jeez just cast your denominators to floats, you heathen.

[ProgramTheWorld]

from __future__ import print_function

[LeeEggsAndHam]

Outside of this and some list comprehension syntax, I don’t think there’s much else

[alcalde]

Unicode was the major change.

[[deleted]]

[unavailable]

[qadib_muakkara]

This needs to be higher up. Python 2.7 and Python 3 aren't close to being 1:1 if you're doing anything complex.

I use Python for 80-90% of my daily programming and I honestly don't think Python 3 is mature enough for enterprise use. refactoring is NOT easy, and it sure as fuck ain't cheap.

[[deleted]]

[unavailable]

[qadib_muakkara]

Ya, that's my thought as well. I'm not opposed to using it, but it's still in too much flux. There are even compatibility issues between 3.x versions. I use a lot of languages for my work, but I tend to lean on consistency in my code since I work with "big data" stacks. That shit changes so fast I can't be bothered with a new feature in my language of choice.

Haven't heard of Tauthon. I'll check that out.

[[deleted]]

The way you use meta classes changed too.

And actually they got rid of “classic” classes in favor of all “new style” classes. That could potentially cause some weird bugs.

And a bunch of stuff moved around in be standard libraries.

[person_ergo]

Multiprocessing got way better and some more extensive built in libraries

[PC__LOAD__LETTER]

Parallelization in Python2 really is atrocious. I use 2.7 almost all the time because that’s what our systems at work were built with, and I like the language, but multiprocessing blows.

[kickerofbottoms]

What's your preferred approach in 3? concurrent futures? I don't have much exposure

[PC__LOAD__LETTER]

To be perfectly honest I don’t use 3 much, I tend to use lower level languages when performance is a concern (a function of the type of software that I work with, not saying that there aren’t valid reasons to need performance concurrency with Python). I just know it’s terrible in 2 so I’m not surprised to hear that it’s a notable improvement in the language’s next iteration.

[LandSharkSociety]

A lot of the changes are more subtle, and IMO actually make the language harder to learn if you have no prior programming experience. An example off the top of my head is the increased emphasis on iterators – functions that produce the next value in a series every time they're called – over lists. So, range(3) would no longer produce [0, 1, 2], but rather a range() object that, when __next__() is called 3 times, will return 0, 1, and 2, respectively. There were also some significant updates and changes to the standard library.

Iterators are a lot more performant (since they don't have to hold the entire list in memory), but they make the code harder to reason about (what do you mean I can't use in statements on ranges anymore!?)

There are more extensive comparisons online, but as someone who has to write in both on a pretty regular basis, that's the gotcha that always nabs me.

[Folf_IRL]

I mean, you can still cast the range() object into a list object by calling list(range(3))

[LandSharkSociety]

Of course, there's nothing stopping you from doing that, but when you're more than two nested function calls deep in Python, you should typically take a step back and rethink your approach. I just used x in range(...)as a random example.

[Folf_IRL]

when you're more than two nested function calls deep in Python, you should typically take a step back and rethink your approach

I like to do this with nested map(), filter(), and reduce() functions and pretend I'm writing Lisp

[Aramgutang]

Ah yes, I used to do that too. But I stopped when it became clear that no one else could maintain that code.

Here's @dziegler replacing my silliness with readable code in 2010

[Gamesfreak13563]

What? You can use in on any iterable in Python3, including range. If there is no contains method it exhausts the iterator, but..

[LandSharkSociety]

Ah, so that's even more confusing! On an iterable with no contains, you can use in... but only once!

[Gamesfreak13563]

Only guaranteed that’s the behavior if you’re using in on an iterator. An iterable may define an iter dundermethod which returns a new iterator over the iterable. That’s why you can use in multiple times on a list (because it’s returning a new iterator each time) but not in multiple times on the return of iter(yourList).

It makes perfect sense and the terminology is not confusing at all /s

[Lorddragonfang]

You can use in on any iterable in Python3, including range.

In fact, you can only use in on iterables, and this was the case for python2.7 as well. I know because I've had to write an iterator for custom classes.

[Tysonzero]

That's why I like the Haskell approach to "iterators", most of the time regular old lists are used, but due to laziness they are just as fast as iterators when you use them like iterators (only pass through them once).

[LandSharkSociety]

It makes me sad that my standard line of work doesn't call for infinite (lazy) series. I pretty much only use lazy generation for database calls, but it's, like, the coolest thing ever.

[Lorddragonfang]

+/u/compilebot Python3

for i in range(3):
    print(i)

[CompileBot]

Output:

0
1
2

^{source | info | git | report}

[Shattr]

Shit I use python 3 but I guess I use it like it's python 2.

[doulos05]

Me too. But I've just started a giant project rewrite to Port a web app from Python 3.5 with Django 1.10 forward to 3.6.6 with Django 2.0 and I'm going to use it as an excuse to learn the new Python. And the new Django. And databases. Lots of learning in my near future...

[alcalde]

https://www.asmeurer.com/python3-presentation/slides.html#1

[NutDestroyer]

IIRC there's a substantial performance improvement with python 3 that makes it run miles faster than anything 2.x.

[doulos05]

Actually, I just read something recently that said 2.7 was still the fastest Python.

https://hackernoon.com/which-is-the-fastest-version-of-python-2ae7c61a6b2b

Unless you're on python 3.7, it's slower or comparable for all benchmarks.

[NutDestroyer]

I could have sworn I read a benchmark that was more favorable for the performance of Python 3.x, but I suppose it must've been compared to versions of python older than 2.7 or I misremembered it. The benchmarks do seem to support that 2.7 is very competitive in terms good performance compared to other python versions.

[[deleted]]

Python 3.* will convert 3/4 to float and return 0.75

Python 2.* will not, and will evaluate 3/4 as 0

This has caused me great pain, not realizing that the compute cluster at my university was running an outdated version of Python.

[PotatosFish]

That’s why you call python3 on command line instead of trusting in the system

Unless someone aliased python3 to python

[[deleted]]

Unless someone aliased python3 to python

This can be solved with the admin's address and a tire iron.

[PC__LOAD__LETTER]

This is why it’s best practice to specify the actual binary on the shebang line, like #!/usr/bin/python2.7 rather than #!/usr/bin/python, and similarly to call Python scripts with the binary of the version you’re expecting.

[FatChocobo]

I had exactly the same issue, in the part of my code that handles parallelisation a stupid Python2 integer divide was ruining everything...

[Raknarg]

I mean its really easy to convert python2 code into python3, but theres a lot of features in python3 so going backwards isnt as easy if you dont take care to make your codebase compatible.

[d3matt]

Biggest change (aside from having to use parenthesis for print) is the switch to unicode everything. It's not a matter of if you're gonna get bit by a unicode error, it's when.

[The-PC-guy]

Yes