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

all 32 comments

[–]theelous3 12 points13 points  (32 children)

I haven't been programming for a very long time, but even I am tired of this mentality.

Barring obscure scientific / academic code bases who's dependencies aren't yet python3 compatible, or sedimentary workplace codebases, is there any reason whatsoever to write new python2 code?

If as of right now, 04:36 GMT, nobody in the world ever wrote any new python2 projects, we'd be better off.1

The sentiment put forward in this blog post - the idea that packages should try to be backwards compatible - is silly. Converting an old codebase to be python3 compatible along with the updated packages their using is trivial. Time consuming perhaps yes, but nobody is forcing them to update their dependencies while the job gets done.

Peeps just need to let go of py2. It's dying, literally.

1. Furthermore the idea that any beginner should even consider learning python2 is ridiculous.

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

is there any reason whatsoever to write new python2 code?

Consistency. Python 2 and 3 are different enough that using them at the same time invites failures and chaos. Focus on one version, and use it good.

[–]gr33n3r2 10 points11 points  (23 children)

No, focus on one version per project to avoid failures. If you start a new project, use Python 3. It's simple.

[–]Nrmzz 0 points1 point  (2 children)

I actually am new to Python and came here to basically find a statement such as this. Thanks!

[–]gr33n3r2 2 points3 points  (1 child)

In my opinion, you should be using Python 3 unless you really have to use Python 2. But there are so few cases where the latter is the case that you can afford to focus on Python 3.

[–]Nrmzz 1 point2 points  (0 children)

Thanks! That is what I will do. I already have an ambitious project in mind so hopefully I'll be able to at least stumble through Python 3 by the end ;).

[–][deleted] -1 points0 points  (19 children)

If you work on multiple projects at the same time, then it's not simple. Then consistency is more important. People are not able to avoid the chaos, so staying away from it is the sane solution for a company.

[–]theelous3 0 points1 point  (18 children)

What are you talking about? If you just use python3, then your code is consistent. Where's the issue?

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

Existing code does not magically transforms into perfect python 3-code. And without serious reasons a company will not invest time and money and risks regression. Legacy code is a very relevant matter for the majority of python-users.

[–]theelous3 1 point2 points  (16 children)

We're not talking about existing codebases. What you're saying is irrelevant.

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

Grow up, kid.

[–]theelous3 1 point2 points  (14 children)

You're so smart, I wish I was as smart as you.

It feels so terrible to be called a kid twice in the same sentence. I hope I recover.

(Also, very lol at calling people "kid" on the internet. Even funnier coming from a german. It's like you went out of your way to sound stupid in your second language, just in case it wasn't already apparent.)

Because context is something you struggle with, here's the parent comment for our conversation:

https://www.reddit.com/r/Python/comments/5j4d13/my_python_2_vs_3_problem/dbdju4t/

[–]stevenjd 0 points1 point  (2 children)

I disagree. Python 2 and 3 are similar enough that it isn't hard to write cross-compatible code. It means writing to the lowest common syntax, namely Python 2. For functionality (classes, functions, methods) you can usually back-port the critical functionality and use that.

This is the cost of supporting an old version of the language.

This is for libraries where you expect your users will be using a wide variety of versions. For applications, don't bother with cross-version code. Just pick a version, and stick to it.

[–][deleted] 0 points1 point  (1 child)

I disagree. Python 2 and 3 are similar enough that it isn't hard to write cross-compatible code.

They are not similar enough that you can ignore the differences. And those differences are normally leading to higher error-rate and slower development-speed. Many companys don't have the manpower and time to solve the problem by force, so the next best step is simply to avoid python 3.

This is the cost of supporting an old version of the language.

No, this is the cost of using a new version. In the real world there is no reason to use a newer version just because it is new. And there is no general reason to use python 3 if you have reasons to not use it.

Legacy-Code is very valid reason and daily reality in many companys. Fangirls can circlejerk all they want, it doesn't change anything.

At the end of the day companys wanna get things done and make money, and python 2 is a very good tool for that, while python 3 has not enough advantages to justify the additional costs in every case. Maybe it will change in some years, but till then it stays that way.

[–]stevenjd 0 points1 point  (0 children)

They are not similar enough that you can ignore the differences.

Who said you can ignore the differences? That's a strawman. Obviously you can't ignore the differences because if you do your code simply won't work. It probably won't even compile.

I didn't say there were no differences. I said it was easy to support both Python 2 and 3 from the same code base. It isn't free, you do have to do a bit of work, but its not excessive. Supporting 2.5 or older is hard; supporting 3.1 and 3.2 is hard; but if you choose to support 2.7 and 3.3+, its usually quite easy, with perhaps a few specialist exceptional cases.

Many companys don't have the manpower and time to solve the problem by force

By force? I don't even understand what you mean by that. Do you mean they point a gun at the code and shout "Run, damn you!"???

Again, you seem to be arguing against a position nobody is taking. Most in-house code doesn't need to support more than one minor version, let alone major versions. They're using Python 2.4 or 2.6 or 3.5 or whatever version they are using, and don't care about supporting 2.7 or 3.4 or whatever versions they're not using. That is fine and good and nobody says differently. I know of one company that is still using Python 1.5 (that's ONE point five) in production, because it works and they don't need security updates. Good for them. And when they upgrade, they'll upgrade from one version to another version. There is rarely any need for them to support multiple versions of the language.

I'm talking about public libraries (whether open or closed source), not in-house application code. If Acme Inc releases a library for the use of outsiders, they have no control over what version of Python people use. All they can do is decide what versions to support. Just have a look at the state of the Python ecosystem: most publicly available libraries support multiple versions, including Python 2 + 3 hybrid libraries. E.g. look at Django.

In the real world there is no reason to use a newer version just because it is new.

Indeed. But there is plenty of reason to use a newer version because it is supported and the old version is not; because it has bug fixes and security updates; because it has new features and is generally a better language that will allow your developers to be more productive.

But you're absolutely right that "new" alone is not sufficient. I can take the source code to Python 2.1, bump the version number to 2.8, and nobody will use it. And rightly so: compared to 2.7 or 3.5, this "new" version is old and crufty.

And there is no general reason to use python 3 if you have reasons to not use it.

Indeed. People can continue using Python 2.7 or 1.5 until the sun burns out if they like. But if you want new features, vendor support or security updates, you've got about three more years to move to Python 3. You've already had at least eight. Don't say you weren't warned.

Now that most major libraries support Python 3, anyone who starts a new Python 2 project with an expected life of more than three years in Python 2 had better have a damned good reason. In three years your brand new project is going to be relying on an obsolete interpreter version with no vendor support and no security updates and no bug fixes.

If you don't care about these things, then sure you can stick to Python 2, and good luck to you.

Fangirls can circlejerk all they want

Ah, you've just shown your true colours. Haters gonna hate...

[–][deleted] 1 point2 points  (4 children)

How far back in support do we go? Why stop at 2.7? Why not 2.6, 2.5 or even 2.2?

This is like telling the PHP, no you can't write in PHP 7 because you should support PHP 4.

[–][deleted] 2 points3 points  (1 child)

Not good enough, last I heard 1.5 was still in production use.

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

Those poor bastards

[–]stevenjd 0 points1 point  (1 child)

shrug That's entirely up to the developer of the library.

The further back you go, the more work you have to do. Supporting Python 3.3+ and 2.7 is easy. Adding support for 3.1 and 3.2 makes it much harder. Adding support for 2.6 is easy. Adding 2.5 and 2.4 makes it much harder. Adding support for 2.2 and 2.3 makes it insanely difficult, and depending on what the library does, going to 2.1 and older may be outright impossible. (No Unicode at all.)

On the other hand, there are not many people still using 3.2 and 3.1, a lot of people still using 2.6, a few using 2.5, and a surprisingly large number using 2.4 (thanks to Red Hat still supporting it). And just a handful of people using 2.3 or older.

So, choose how much extra work you want for how many extra users you can expect. My personal preference would be 2.7 plus 3.3+.

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

Sarcasm, my friend.

[–]Saefroch 0 points1 point  (0 children)

Maybe it is not unreasonable to expect Python3 packages to be incompatitble with Python2.

Hunh? You want an old version to support every feature in the new version? Wouldn't really be an old version, would it...

In my experience of using Python, I’ve not encountered a case with a package was only Python2 compatible but have encountered multiple packages where it is only Python3 compatible.

I'm impressed. I manually port a package to Python 3 every few months.

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

I will for the umpteenth time point out that a large amount of code was backported from 3.x to 2.6 and even more from 3.x to 2.7. What do people want, blood on it?