standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

> 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.

you see that's the problem with py3. instead of slowly removing the
features one by one till the end they made a jump. the problem is not
with the jump but with other libraries/packages that depend on py2.
what i felt was if the new version was available as soon as it is into
the stream, developers/users try to use them and get accustomed. now
they follow this. they have frozen py3 for may be 2-3 years so ppl
would move slowly to py2.6 ,2.7, 2.8... most. also the corporate
companies are the most influential.

also a point to note: if new updates keep on coming (for eg. daily
antivirus update) developers tend to accept and move on *easily*.

i am not an expert in programming/interpreter design/library writing/
packaging. i just wanted the standard library *too* to be pluggable,
not just the applications based on it.
i am not even experienced in python to make bold accusations so all i
can say is 'how it would be if?' and i always stick to one thing 'why
not?'.

> 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 interpreter
> evolves I have to rewrite even the old ones. Not appealing. Why develop
> the interpreter at all then?

if you are app developer you needn't rewrite anything. that is the
main point here! just specifying the interpreter and library version
is enough every thing has to work like magic. as the previous
library&interpreter wont be removed (unless and until it is your will)
u can use them. thats how everybody would like it to be.

as for a library writer is concerned: as you say it depends on certain
things like other libraries,interpreter,etc. but i would like to say
that change is inevitable. if some core developer has to change
something he might change. and if you have to update your library you
have to. this applies to the interpreter too. what python now does is
make every update work with the minimal set (giving minimal backward
compatibility) plus the new features too. which is exactly the right
thing. what i wanted is the users have to be aware now and then when
of the modification, deletion, addition stuff not in every release as
in py3k. then the whole backward incompatibility issue would be
*dissolved* or what i mean is *diffused* and ppl dont even know that
they have switched over to a very new thing.



> In other words: the problem is solved by somehow solving the problem -
> but not by a concrete solution you propose?

as i told before i neither know the problem nor the solution. i just
wrote my ideas/imagination down

> 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.

yes you are right. python has a lot of bindings to a lot of stuff. but
it is the strength and weakness. not exactly pythons weakness but with
the thing on the other side. yes it may be looking complex because
most of the 'standard library' system was not designed to be adhoc/add-
on/pluggable from the start.