3 ms·
How 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 sta
by raziel2p 6y ago
How 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?