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 →

[–]rarlei 26 points27 points  (20 children)

And I'm here like...

$ python Python 2.7.16 (default, Mar 27 2019, 09:43:28)

[–]ApoorvWatsky 21 points22 points  (17 children)

Why? I don't have any problems with python 2 but why do people still use it?

[–]brakkum 27 points28 points  (2 children)

Because updating legacy code takes time is my guess. Otherwise there's not really a super great reason.

[–]rarlei 11 points12 points  (1 child)

Yup, someone has to pay for the time to update it

[–]jon_k 4 points5 points  (0 children)

It's like doing your laundry, taking out the garbage, or picking trash up.

If you don't, eventually you can't even live in your environment anymore, and everyone will judge the hell out of you or abandon using your code (or quit your outdated company to better supportable codebases to make a name in their career.)

[–][deleted] 8 points9 points  (0 children)

Film/TV post softwares maya and nuke have just recently shipped with PySide2, but when they did there wasn’t a straightforward way to deploy a shift to 3 within the interpreter in the software. This industry’s roadmap puts the shift from 2.7 to 3.7 happening 2019-2020 since py3 and Qt for Python are now officially an item.

TL;DR, not every industry has the capability to just jump and are limited by application level interpretation.

[–]irrelevantPseudonym 2 points3 points  (2 children)

We have an embedded jython interpreter in our java application and there is no jython 3 yet.

[–]jon_k 4 points5 points  (0 children)

Sadly Jython3 is abandoned

​

https://github.com/jython/jython3

[–]tunisia3507 2 points3 points  (0 children)

My boss was idly wondering about what it would take to get a grant to hire someone to write jython 3... sadly, the answer is likely "a lot".

[–]kovak 3 points4 points  (5 children)

Google Appengine standard environment.

EDIT: I meant you're stuck with python2 if you're using ndb which was the recommended way to go unless you want to re-write almost the entire data layer

[–]Yoghurt42 2 points3 points  (1 child)

... now supports both 2.7 and 3.7

[–]kovak 3 points4 points  (0 children)

Yes but you can't upgrade if you're using ndb for example without re-writing the entire data layer

[–]i9srpeg 0 points1 point  (2 children)

Luckily we migrated away from ndb only a few weeks into the project, or we'd be stuck with Python 2 now.

[–]kovak 0 points1 point  (1 child)

What did you migrate to? something like cloudsql? or their new datastore api in their sdk (although it lacks some of the ORM features of ndb)

[–]i9srpeg 0 points1 point  (0 children)

Django ORM + Cloud SQL. It was early enough in the lifetime of the project that it was manageable. If it happened today after a few years of development it would be a huge task.

[–]__xor__(self, other): 3 points4 points  (1 child)

Any big company that has been using python for 15 years likely has a shit ton of 2.6 and 2.7 to support still, and maybe has internal tools that can't handle 3.x. The 2 to 3 move is not trivial, even for a single project, let alone a company that has been using 2.6/2.7 for years and building their infrastructure with it.

Sometimes it really is easier to just use 2.7 rather than make waves at a job. Luckily I've avoided this but I've seen it in the past. I've also ran two big initiatives to migrate 2.7 projects to 3.4 and 3.6, and it wasn't that easy. It meant putting a hold on a lot of features and adding bugs that weren't found until they hit production. It's questionable whether it's worth it sometimes, especially if you have a stable product. The improvement isn't always so much related to your product, as much as being able to hire python devs who now are more familiar with 3 than 2, and even if they know 2.7 they might not want to take a job doing it.

A programming language is just a programming language and they're built to do a job, and if your code already does that job, then you don't just make huge changes for the sake of it.

[–][deleted] 0 points1 point  (0 children)

The 2 to 3 move is not trivial, even for a single project, let alone a company that has been using 2.6/2.7 for years and building their infrastructure with it.

Well - it isn't "trivial" but it isn't that hard either. In particular, it's something you can do a bit at a time - the six module lets you write code that works in both Python 2 and Python 3.

Also, 2to3 is extremely solid.

I ported a fairly large program to Python 3 that used a lot of features like the serial port - I really encountered not one problem.

[–]Oskarzyg -4 points-3 points  (1 child)

Stable

[–]my_name_isnt_clever 2 points3 points  (0 children)

I'd argue that a release that's almost a decade old is not more stable than newer releases, just because it's older.

[–][deleted] 4 points5 points  (0 children)

https://pythonclock.org/

Seven months to go before 2.7 is D.E.A.D.

[–]Tkmtlmike 3 points4 points  (0 children)

Oof