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. 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
