Python, Be Bold!

Abdur-Rahmaan Janhangeer arj.python at gmail.com
Thu Jan 2 14:37:57 EST 2020


Oh auto-3rd party modules is a mess. Suggesting updating only the
interpreter. We can have a pre-scan which warns the user that upgrading
will make the following packages no longer compatible. But that's one aim
of venvs i think, is to confine packages to projects, not to the
interpreter.

No java does not have such a feature, it's a suggestion that's unrelated to
Java.

For distributing to clients, you don't rely on the user interpreter for
packages. As far as I know, some companies select let's say version 1.0.5
of a library, and ... they keep it internal, they might modify it as
desired. It becomes a home pet. They distribute this version with their
project. Even if the library is at 2. they use the modified 1. for
increased stability. That's one extreme.

Having a sort of .jar running with the system interpreter concerns syntax
and enforced standards.

To further ease dist, much work is required to be done on the project
format itself. If i remember well, a PEP proposed to install 3rd party
packages in a folder in the project, which might further enhance the
process.

Having a Python-specific executable allows you to go to whatever length you
desire to make project bundling an easy task. The other effort is to get
your interpreter/VM running on as many hardwares as possible. This includes
the effort to make it lighter, faster etc. It might entails the complete
removal of 3rd party packaging interpreter side or not using it when
running the specific executable.

I believe Python should be able to run on any device. I believe that my
Python code should go everywhere. It pains me to see a project not choosing
Python as an add-on scripting language due to the size of the interpreter
or things of the sort.


More information about the Python-list mailing list