standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

On Nov 12, 6:07 pm, "Diez B. Roggisch" <de... at 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-dev at 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.