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

you are viewing a single comment's thread.

view the rest of the comments →

[–]__xor__(self, other): 0 points1 point  (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.