standard libraries don't behave like standard 'libraries'

[Diez B. Roggisch]

Sriram Srinivasan schrieb:
> 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.

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