I hate Python 2 and Python 3, but I love Python

Even though the new version is around, people would like to call it “Python 3” which makes it sound like a different language.

“Python 2” and “Python 3”, I hate them both. I love Python!

I hate “Python 2” and “Python 3”, because people need to decide between them, project maintainers have to keep compatibility for both and sometimes even for multiple version of 2.7.x and 3.x. It slows down the development of my favorite libraries.

Seems Python is not cross-version compatible, what ? Yes, that’s right. A beautiful selling point of Python is being a cross-platform language, but lately it’s becoming non cross-version compatible due to the third party libraries support and some other factors.

Upgrading from legacy Python version to latest takes changing some statements and how you handle str or Unicode and some other tiny stuff, a tool like 2to3 would do it in 95% of the times, but the problem is not your code only, you have to deal with all of your third party libraries and your third party library developers have the same issue. That’s the bleeding wound.

Lemme tell you a cute short story .

The Cute Short Story

When I wanted to start a project, after discussion what should the stack be, we decided we need:

• Django
• Django Rest Framework
• Django Storages
• Boto
• Mongodb
• Redis
• PostgreSQL
• Pillow
• Python Requests
• Twillio
• Gevent
• Gunicorn
• Celery
• Mock
• Python Coverage
• Fabric
• ipdb

And many more of these, so our team was insisting on using Python 2, why ? simply because we might need a third party dependency that is compatible only with “Python 2” and if we start with “Python 3” that might cause us loosing an eye or AKA money.

All of the above amazing third party libraries worked well with the latest version of Python except Fabric that has a “Python 3” fork.), all of them work exactly on latest or legacy version of Python and still we haven’t hit a issue about third party library compatibility with “Python 3”.

Still, we went with legacy version, that pissed me off, but in order to keep our work sane or fool each other, we wrote the code to be compatible with “Python 3”. There’s nothing special in the code base that is might break by using “Python 3” as run-time.

Our CI runs the test for both legacy version and latest and we never had to change the code to be “Python 3” compatible, it just works. The magic in there? We only follow Python recommendation.

The fear of dependencies incompatibilities with legacy and latest version of Python.

Does that mean Python is becoming cross-version incompatible ?

That’s scary and I don’t want to think about it, maybe I’m overreacting, maybe I took this seriously or making a big deal out of it.

Problem is, supporting legacy code is good for just some years, but not for a decade, Python 3 came out 2008 and people are still are suspicious or lazy to move on.

Dropping Python legacy should have started a long time ago, but still it’s not too late, we need to start and encourage others to drop it and move on. We are holding the development back.

Tons of awesome new features in Python now, features that people choose other languages to make their next projects.

• Coroutines async await.
• Type checking and hinting.
• Static static analysis tools.
• Unicode
• Better exception handling
• String formatting
• Bytes vs String
• Much nicer multi-threading
• etc…

The list goes on and on…

Start your next project with latest version of Python, encourage and push third party library developers to move to latest, if they’re don’t or can’t, fork it and do it yourself, it’s Open Source!

Choose the legacy version only and only when you have no other choices due to vendor lock or bleeding dependencies compatibility.

A code for “Python 2” is not simply “code”, it’s a code that works with older version of “Python”, a legacy code that is not updated, if you write a code that Python (as latest version) cannot run it, that code is broken, that code is not working anymore. It has to be updated, upgraded to latest.

I understand the current dependencies and third party modules are the main player in this scenario, but would that worth having 2 separate languages or be a good excuse for it?

It’s a dilemma, an annoying one. Having 2 Python run-times on a system is weird. Using virtualenv to cover it up is not gonna work .

PyBabel Rises!

If we’re going to continue in this direction, Someday we might have to use another tool to write a language with a syntax like Python to produce “Python 2” and “Python 3” compatible source and later supports “Python 4”, people won’t be writing “Python” anymore but a language like “Python” that compile or transpile something that different Python implementation will run it.

That time we gonna think about a language that compiles to something to be runnable on:

• Python 2
• Python 3
• Python 4
• PyPy
• pyston
• Jython
• IronPython

Having a distance between “Python 2” and “Python 3” will might end up in a situation like that. Who knows, something like like 2to3 might be just a start for tools like that.

Don’t let Python be[come] cross-version incompatible.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!