standard libraries don't behave like standard 'libraries'

[Benjamin Kaplan]

On Thu, Nov 12, 2009 at 12:05 PM, Sriram Srinivasan
<naughtysriram at gmail.com> wrote:
>> 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.
>

The freeze was put in place so that the other implementations of
Python, like Jython and IronPython, have a chance to catch up with the
reference CPython implementation. It's not so people will slowly move
up. FWIW, people knew for years what was going to change in Python 3.

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

So you're saying that we'd have multiple versions of the interpreter
running at the same time, but they all have access to the same memory.
That wouldn't just require a change to Python, that would require a
change to the way all modern operating systems work.

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

Actually, that's not entirely true. New versions to break things
Consider these statements

as = ['a','a','a']
with = [1,2,3]
It's legal in Python 2.4 or earlier, a warning in Python 2.5, but
illegal in Python 2.6

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


It is pluggable. The standard library consists of Python modules like
any other. 2.6's multiprocessing module is just an incorporation of
the pyprocessing module for instance. The point of the standard
library is that you can count on it being there, and you can count on
it having certain features, given your interpreter version. You can
also be sure that anytime a new version of Python comes out, those
modules will be compatible.


> http://mail.python.org/mailman/listinfo/python-list
>