4 ms·
The annual release cadence is a disaster for Python. I've already run into countless interpreter compatibility issues where new code has to run in a different e
by Areading314 6y ago
The annual release cadence is a disaster for Python. I've already run into countless interpreter compatibility issues where new code has to run in a different environment. 3.6, 3.7, 3.8, and now 3.9 are all still officially supported, which just adds a huge mental burden when reading python code, because you have to remember when each feature was released.
- swalsh 6y agoI still have code that relies on 2.7.... yes, i'm ashamed of myself :(
- raziel2p 6y agoHow does it add burden when reading code? Writing code, sure, but only when you don't research the environment you're going to be deploying into. Unless you started working with Python like last year you probably remember when new useful features were released, and for stuff you haven't used before, the Python documentation always tells you when it was added.
- Areading314 6y agoSay your production environment runs on python 3.7. New developer on the team opens a pr and you see dataclasses, a class attribute type hint, maybe a walrus operator and some required keyword-only args. They say they've tested the code in their local virtual environment and it runs. Which of these features break the build and which are the new best practices? Sure ci will catch most of these but maintaining 100% code coverage is a significant burden and very rare in practice.
- hkjhakjsdf 6y agoIf your new developer installs a higher version than you are running in production, the issue is with your on boarding process, not python release cadence.
- Areading314 6y agoThe issue is that python now is effectively 4 languages at once, making all aspects of working with it more complex and prone to error, onboarding included
- pjmlp 6y agoNot now, breaking changes even between minor versions, have always been a thing in Python.
- dagmx 6y agoThat sounds like a work culture issue. This would apply to any compiler or language. Why isn't everyone on the same version? This hardly seems like a Python specific issue.
- angrais 6y agoShouldn't your development environment mirror production, e.g. by pinning the python version to 3.7 using a combination of poetry and pyenv? I thought this was standard practice?
- screye 6y agoPython should do Long-term-support releases, and annual stable releases. (an old suggestion too - https://www.python.org/dev/peps/pep-0407/ https://www.python.org/dev/peps/pep-0407/) Unlike 2.7, I do not see a consensus on a 'standard' version for python 3 between 3.4-3.7. (not any of the others, that's for sure)
- pjmlp 6y agoI love to use Python as counter example of C++'s complexity. Have been using Python on and off since 1.6 and not only is the documentation also quite impressive, when one sums up language reference + library, just like ISO documents, its changes between versions make a Pub Quiz a very easy task. The language is probably the new Basic, but to achieve 10 dan in Python there is plenty of stuff to chew on.
- mdziwny 6y agoA good CI/CD, with some precommits and a containerised stack should avoid you all those troubles. Also, nothing force you to update to the newest version, you can stay approximately 5y on the same release, but keeping the pace makes the upgrades less costly and less risky in the long run because you don't accumulate deprecated features, you're forced to cleanup the abandoned dependencies, ... It also makes the team happier and more attractive when recruiting.