Sriram Srinivasan schrieb:
On Nov 12, 6:07 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
ok let me make it more clear..
forget how you use python now.. i am talking about __futuristic__
python programming.
there is no more python2.x or python3.x or python y.x releases. there
is only updates of python and standard library say 1.1.5 and 1.1.6.
let the difference be an old xml library updated with a new regex
support.
i am coding my program now.
i want my application to be compatible with 1.1.5 library
use library 1.1.5
import blah form blahblah
...
...
i cannot use regex feature of xml in this application
i then update my library in the evening
now both the libraries are present in my system.
now i try using the new feature
use library 1.1.6 #thats all now i get all features
import blah from blahblah
This is not futuristic, this is state of the art with PyPI & setuptools.
You still haven't addressed all the issues that arise though, regarding
different python interpreter versions having different syntax and ABI.
Diez
haha... it would be awesome if they implement it in the 'future' .. i
posted the same to python-...@python.org, it seems the distutil is
getting a big overhaul. (i hope they make a new uninstall option for
setuptools n easy_install) they say there are many ways to do that
using pkg tools... but python wants one and only one way- the python
way.
regarding issues:
1.security is always a issue
2. regarding problems like with statement you mentioned earlier.. i
think there will be a basic feature set that is common for all
versions of add-on libraries.
So all libraries written have to use the common subset, which - unless
things are *removed*, which with python3 actually happened - is always
the oldest interpreter. And if a feature goes away, they have to be
rewritten with the then common subset.
In other words: as a library writer, I can't use shiny, new & better
features, I'm stuck with the old stuff, and whenever the intepreter
evolves I have to rewrite even the old ones. Not appealing. Why develop
the interpreter at all then?
3.when you want the new feature you have to update your python
interpreter
use interpreter 1.5.2
may trigger the proper interpreter plugin(responsible for additional
feature) to load and add functionality.. its simple to say but it is
hard to make the compiler pluggable, may be they figure out.
>
use library x.y.z
while issuing this command the default interpreter has to
automatically resolve dependencies of the core c/cpp static libraries
and other shared libraries. so that must not be an issue. if they have
implemented this much, dep solving is nothing.
In other words: the problem is solved by somehow solving the problem -
but not by a concrete solution you propose?
futuristic python may also contain an option for compiling a module
into a static library. so we can code python libraries in python
(mostly) itself. think of pypy. it is already state of the art.
PyPy is cool, but by far not advanced enough to replace external,
C-based libraries such as NUMPY and PyQt and whatnot.
I don't say that the current situation is by any means ideal. There is a
lot to be said about package creation, distribution, installation,
removal, dependency handling, and even system-packaging-integration if
one likes.
You IMHO just add another layer of complexity on top of it, without
proposing solutions to any of the layers in between, nor your new one -
namely, the interpreter version agnosticism.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
