←back to thread

317 points est | 1 comments | | HN request time: 0.207s | source
Show context
blindseer ◴[] No.17448804[source]
My biggest problem with this change (and dataclasses) is that it is not backward compatible (I know that a backport of dataclass is available, but it is only for Python 3.6). Can people tell me how they deal with this? Are you using features that are only available in the version of Python all your colleagues / users have access to? Are you using the latest version of Python and hoping your colleagues and users can upgrade to that version of Python?

One main reason in my opinion as to why Python 2.7 stuck around for so long was that everyone agreed that it was the last stable version of Python 2, and the devs could make Python 3 changes without worrying significantly about backward compatibility. I've been using Python3 since Python 3.3 but have had to write code that was Python 2 compatible for large code bases for about 5 years because I knew colleagues / users of my packages would not upgrade. This meant using a select subset of features in Python 3 that had been backported to a version of Python 2.7 that I knew I could get my colleagues / users to upgrade to. It has been great to watch the language evolve and Python 3 really gets a lot of things right, but adding breaking syntax features every minor release is extremely annoying. I have to have a mental checklist of all the different possible subsets of features I have access to given a minimum version of Python I want to support. I've spent the last couple of years in my professional career converting large Python 2 only code bases to Python 3.3+. But if someone wants to use async, I need to bump the minor version. If someone wants to use type hinting I have to bump the minor version. If someone wants to use f-strings I have to bump the minor version. If someone wants to use data classes I have to bump the minor version. It's nuts (to me anyway)!

This sounds rant-y but I genuinely want to know what other people are doing to mitigate this. I love Python! I have spent years advocating its merits. But thinking about large codebases in Python just worries me and the future doesn't look promising here. Are Python developers hoping that once 2020 arrives they'll have a stable Python release and work on Python 4. We'll have the Python 2/3 split all over again!

My personal opinion is that Python needs an officially maintained translator for the latest Python features back to older versions. My current favorite package is py-backwards [0] but it is rather unmaintained at the moment.

[0] - https://github.com/nvbn/py-backwards

replies(5): >>17448827 #>>17448911 #>>17449596 #>>17451139 #>>17452566 #
1. systoll ◴[] No.17449596[source]
They've made backward incompatible changes within python 3's history, but none of the things you've listed are among them. Anything with ':='s, f'strings' etc. is invalid in python 3.0, so existing [working] code isn't affected.

With 2 vs 3 there were a large number of breaking changes, so effort spent adding new features to the 2.x lineage made sense. But if you're not able to get someone to update from 3.6 to 3.7 for dataclasses, is a 3.6.7 that supports them [but doesn't reserve 'async'] likely to be any different?

> Are you using features that are only available in the version of Python all your colleagues / users have access to? Are you using the latest version of Python and hoping your colleagues and users can upgrade to that version of Python?

If you have access our software, you have access to http://python.org -- that's never the issue.

For colleagues... everyone has 3.6.4-3.6.6 on their work computers unless they've actively prevented it.

We don't have anything using python for external users. If we did, I wouldn't want to assume that they already have python installed at all. I'd be inclined to look into PyInstaller for distributing that, and then we could depend on whatever version we wanted.