this post was submitted on 04 Aug 2024
60 points (100.0% liked)
Python
6347 readers
1 users here now
Welcome to the Python community on the programming.dev Lemmy instance!
๐ Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django ๐ฌ)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
๐ Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
๐ Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
โจ Python Ecosystem:
๐ Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- Pythรถrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well that's one solution.
We wouldn't do this because we have a policy of modifying as little as humanly possible on the target system, because of the nature of some of our customers: we may not have the right to modify stuff right and left willy-nilly on those customer's systems, and if we do, we have to justify why with a lot of paperwork. So we don't: we install our stuff in one very formal, very stable spot of the hard disk (on Windows, c:\Users<username>), install missing modules, stick an icon on the desktop and that's it.
Historically, we also propose to install Python on the system if it's missing (used to do that system-wide) and advise our customers to install it system-wide too if they did it themselves so we wouldn't have to modify our installer (again, if we do, we have to justify the change when the customer is under configuration control, so we try to avoid change). Not anymore obviously.
So yeah, we wouldn't install Miniconda just for the purpose of not changing our installers. At this point, that's enough change that I can just rewrite the installers: either way, I'll have to communicate the change to the customers, so I might as well do it right.
But my point was, if Python gracefully handled backward compatibility - as in, for example, you put in the shebang or near the shebang that you want the interpreter and pip to behave like, say, Python 3.10, and Python4.56 behaves like 3.10 did years later - then this is unnecessary work that I wouldn't have to do.
I had to rewrite our installers and other things to deal with Python 3.12's new forcibly-enforced kosher way ot doing things because it won't do thing any other way and compatibility be damned. That's my beef with Python: after all this time, it's still unstable and prone to breaking existing codebases.
It's a real problem for us and it has been for a long time: code that's out there and working is liable to quit working when the Python interpreter changes. I have no idea how a 33-year-old language, ultra-widely used language such as Python is allowed to change regularly with little regard to backward compatibility like it was an early beta weekend project. This is truly unprofessional and it completely boggles my mind.