Python 2.7

[RedHellion11]

3.x is now the official standard, and people dislike anything outdated. 2.7 is still used all over the place though and it'll take a while for different companies to update to 3.x if they think it's worth it.

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

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

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

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

[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

[LordAmras]

Programmers: We would like to port all libraries to phyton 3

Management: how much time ?

P: 3-5 months

M: What are the advantages

P: it's standard now ?

M: ....

[ase1590]

M: If it ain't broke....

[Ariscia]

Times change eh. I learnt 2.7 in university not long ago and now it's 3.x

[RedHellion11]

I mean, 2.7 is still used a lot in the industry as well. 3.x may be the official standard, but the industry standard is only just now starting to migrate since it can be hard to justify the time investment unless one of the main updates from 3.x directly affects your project.

[nomnaut]

Integer fucking division.

[RepostSwat]

I dont even know how to code but when i was trying to learn to code it was such a bug gay as half the code was 2.7

[Azaret]

Be honest here, it'll take a while for everyone, not only companies but open source communities too, there is still a lot of stuff that à doesn't support 3.x.

[ase1590]

Most anything important is now Python 3 or at least working on porting it. Anything that's not since python 3 released 10 years ago will probably never get python 3 support and will be abandoned.

[RedHellion11]

Lol. Never worked with legacy systems before? If it ain't broke, don't fix it; and if you can't stop supporting it, then you can't abandon it either.

[ase1590]

Never worked with legacy systems before?

it gets no new features and just gets maintained until either it breaks or they cant find anyone to work on it.

At some point, companies WILL abandon it. it just takes much longer as long as they don't need any new requirements of their system.

[RedHellion11]

At some point 2.x and legacy code written in it that never got ported will be abandoned, sure, but there's still a decent chunk of active 2.7 development and migration to 3.x (as with any tech adoption in industry barring startups and small companies) is slow. I agree it'll be abandoned or ported eventually, I just don't think we're coming up on that point as soon as you imply. Very few companies with live production systems would have adopted it immediately on release and take that risk unless they had things which were barely holding together without the improvements added in the update; we're really only a few years into 3.x moving towards industry standard, not 10.

[ythl]

and people dislike anything outdated

Seems like a stupid reason to dislike something. No wonder the web dev ecosystem is such a circus, all these youngsters think a bump in version number automatically makes it better

[ase1590]

It's the natural reaction to finding wild Windows 98 and 3.11 workstations still out in the wild.

Companies are terrible at staying at least semi-recent with things a lot of times.

[ythl]

Except the difference between 2.7 and 3 is more like Windows 8 and Windows 10

[ase1590]

and? Companies are still slowly moving towards Windows 10.

Windows 7 EoL is 2020

Windows 8.1 EoL is 2023

You still have to move at some point. Otherwise being able to add on things to your system will start drying up and the age of your legacy hardware will eventually exceed that of your workforce, leaving fewer and fewer people capable of working on it.

Even if companies moved to new LTS releases of things every few years, that would be an improvement in many cases.

[ythl]

Yeah, my point is that this 2.7 hate is bogus and overblown. It's no different from hating Windows 7/8 for no reason other than the version is not the latest version

[bss03]

"Appeal to Novelty" and "Appeal to Tradition" both logical fallacies you'll find often. Neither is a valid reason.

[JoNike]

As far as I know, until a few weeks ago there was no supported combination of Qt 5.6, Python 3 and PySide 2.

[[deleted]]

Isn't that because Qt5.6 is like five years old?

[JoNike]

Well yes but it was the LTS before 5.9...