Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > standard libraries don't behave like standard 'libraries'

Reply
Thread Tools

standard libraries don't behave like standard 'libraries'

 
 
Sriram Srinivasan
Guest
Posts: n/a
 
      11-12-2009

> You are describing a lending library, which is not the only sort of
> library. My personal library doesn't do any of those things. It is just a
> room with shelves filled with books.


how i see is all libraries are libraries, for a personal library you
are the only customer and you are the management too.!

> Words in English can have more than one meaning. Horses run,
> refrigerators run, and even though they don't have either legs or motors,
> programs run too. The argument that code libraries don't behave like
> lending libraries won't get you anywhere.


first this is not an argument at all...i clearly stated these were my
imaginations cum ideas.

> Since library features are tied closely to the features available in the
> Python interpreter, the way to use library 2.5 is to use Python 2.5. You
> *might* be able to use library 2.5 with Python 2.6 or 2.4; you absolutely
> won't be able to use it with Python 1.5 or 3.1.


i am not talking about the past..past were experiences! that the
developers had and what is happening today *might be* another
experience for the future.

 
Reply With Quote
 
 
 
 
Diez B. Roggisch
Guest
Posts: n/a
 
      11-12-2009
Sriram Srinivasan schrieb:
> On Nov 12, 6:07 pm, "Diez B. Roggisch" <(E-Mail Removed)> 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 http://www.velocityreviews.com/forums/(E-Mail Removed), 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
 
Reply With Quote
 
 
 
 
Sriram Srinivasan
Guest
Posts: n/a
 
      11-12-2009
> 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.
 
Reply With Quote
 
Benjamin Kaplan
Guest
Posts: n/a
 
      11-12-2009
On Thu, Nov 12, 2009 at 12:05 PM, Sriram Srinivasan
<(E-Mail Removed)> 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
>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Making html button behave like hyperlink WJ HTML 11 03-03-2011 11:27 AM
Cisco switch behave like an hub Moti.Ba@gmail.com Cisco 6 02-26-2010 11:35 AM
Any way to make a CheckBoxList behave like a RadioButton? MattB ASP .Net 6 09-21-2006 07:08 PM
How to convert a fast ethernet interface in a Cisco Router to behave like a serial interface Moloy Cisco 1 03-18-2006 02:16 PM
Does assignment operator have to behave exactly like copy constructor bluekite2000@gmail.com C++ 12 06-16-2005 09:44 PM



Advertisments