Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   standard libraries don't behave like standard 'libraries' (http://www.velocityreviews.com/forums/t705033-standard-libraries-dont-behave-like-standard-libraries.html)

Sriram Srinivasan 11-12-2009 08:31 AM

standard libraries don't behave like standard 'libraries'
 
I guess why every programming language has some kind of a 'standard
library' built in within it.
In my view it must not be called as a 'library' at all. what it does
is like a 'bunch of built-in programs ready-made to do stuff'.

Lets see what a 'library' does:

1. offers books for customers
1.1 lets user select a book by genre, etc
1.2 lets user to use different books of same genre, etc
1.3 lets user to use books by same author, etc for different genre

2. keeps track of all the books + their genre
2.1 first knows what all books it has at present
2.2 when new book comes it is added to the particular shelf sorted by
genre,author,edition, etc.
2.3 when books become old they are kept separately for future
reference
2.4 very old books can be sent to a museum/discarded

I guess no standard library does the minimum of this but wants to be
called a library.

As a python user I always wanted the standard library to have such
features so the user/developer decides to use what set of libraries he
want.

consider the libraries for 2.5 ,2.6, 3K are all available to the user,
the user selects what he wants with something like.

use library 2.5 or use library 2.6 etc.

The 2 main things that the library management interface has to do is
intra library management and inter library management.

intra library mgmt- consider books to be different libraries
(standard, commercial, private, hobby, etc)
inter library mgmt- consider books to be modules inside a library
( standard, commercial, private, hobby, etc)

if somehow we could accomplish this kind of mother of a all plugin/ad-
hoc system that is a real breakthrough.

Advantages:

1. new modules can be added to the stream quickly
2. let the user select what he want to do
3. modules (that interdepend on each other) can be packed into small
distribution and added to the stream quickly without waiting for new
releases
4. solution to problems like py 2.x and 3.x
5. users can be up to date
6. documentation becomes easy + elaborate to users
7. bug managing is easy too
8. more feed back
9. testing also becomes easy
10. many more , i don't know.. you have to find.

Python already has some thing like that __future__ stuff. but my
question is how many people know that? and how many use that? most of
them wait until old crust gets totally removed. that is bad for user
and python. that is why problems like py2.x py3.x originate. If there
is a newer book collection it must always be available at the library.
i must not go to another library to get that book.

These are just my views on the state of the standard libraries and to
make them state-of-the-art..! ;)






Diez B. Roggisch 11-12-2009 10:56 AM

Re: standard libraries don't behave like standard 'libraries'
 
Sriram Srinivasan schrieb:
> I guess why every programming language has some kind of a 'standard
> library' built in within it.
> In my view it must not be called as a 'library' at all. what it does
> is like a 'bunch of built-in programs ready-made to do stuff'.
>
> Lets see what a 'library' does:
>
> 1. offers books for customers
> 1.1 lets user select a book by genre, etc
> 1.2 lets user to use different books of same genre, etc
> 1.3 lets user to use books by same author, etc for different genre
>
> 2. keeps track of all the books + their genre
> 2.1 first knows what all books it has at present
> 2.2 when new book comes it is added to the particular shelf sorted by
> genre,author,edition, etc.
> 2.3 when books become old they are kept separately for future
> reference
> 2.4 very old books can be sent to a museum/discarded
>
> I guess no standard library does the minimum of this but wants to be
> called a library.
>
> As a python user I always wanted the standard library to have such
> features so the user/developer decides to use what set of libraries he
> want.
>
> consider the libraries for 2.5 ,2.6, 3K are all available to the user,
> the user selects what he wants with something like.
>
> use library 2.5 or use library 2.6 etc.
>
> The 2 main things that the library management interface has to do is
> intra library management and inter library management.
>
> intra library mgmt- consider books to be different libraries
> (standard, commercial, private, hobby, etc)
> inter library mgmt- consider books to be modules inside a library
> ( standard, commercial, private, hobby, etc)
>
> if somehow we could accomplish this kind of mother of a all plugin/ad-
> hoc system that is a real breakthrough.
>
> Advantages:
>
> 1. new modules can be added to the stream quickly
> 2. let the user select what he want to do
> 3. modules (that interdepend on each other) can be packed into small
> distribution and added to the stream quickly without waiting for new
> releases
> 4. solution to problems like py 2.x and 3.x
> 5. users can be up to date
> 6. documentation becomes easy + elaborate to users
> 7. bug managing is easy too
> 8. more feed back
> 9. testing also becomes easy
> 10. many more , i don't know.. you have to find.
>
> Python already has some thing like that __future__ stuff. but my
> question is how many people know that? and how many use that? most of
> them wait until old crust gets totally removed. that is bad for user
> and python. that is why problems like py2.x py3.x originate. If there
> is a newer book collection it must always be available at the library.
> i must not go to another library to get that book.


You are greatly oversimplifying things, and ignoring a *lot* of issues
here. The reason for __future__ is that it can *break* things if new
features were just introduced. Take the with-statement, reachable in
python2.5 throug

from __future__ import with_statement

It introduces a new keyword, which until then could be happily used as
variable name.

So you can't arbirtarily mix code that is written with one or the other
feature missing.

Then there is the issue of evolving C-APIs (or ABI), wich makes modules
incompatible between interpreters.

And frankly, for most of your list I don't see how you think your
"approach" reaches the stated advantages. Why is documentation becoming
easier? Why bug managing? Why testing?

I'm sorry, but this isn't thought out in any way, it's just wishful
thinking IMHO.

Diez

Sriram Srinivasan 11-12-2009 11:18 AM

Re: standard libraries don't behave like standard 'libraries'
 
On Nov 12, 3:56*pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> Sriram Srinivasan schrieb:
>
>
>
> > I guess why every programming language has some kind of a 'standard
> > library' built in within it.
> > In my view it must not be called as a 'library' at all. what it does
> > is like a 'bunch of built-in programs ready-made to do stuff'.

>
> > Lets see what a 'library' does:

>
> > 1. offers books for customers
> > *1.1 lets user select a book by genre, etc
> > *1.2 lets user to use different books of same genre, etc
> > *1.3 lets user to use books by same author, etc for different genre

>
> > 2. keeps track of all the books + their genre
> > *2.1 first knows what all books it has at present
> > *2.2 when new book comes it is added to the particular shelf sorted by
> > genre,author,edition, etc.
> > *2.3 when books become old they are kept separately for future
> > reference
> > *2.4 very old books can be sent to a museum/discarded

>
> > I guess no standard library does the minimum of this but wants to be
> > called a library.

>
> > As a python user I always wanted the standard library to have such
> > features so the user/developer decides to use what set of libraries he
> > want.

>
> > consider the libraries for 2.5 ,2.6, 3K are all available to the user,
> > the user selects what he wants with something like.

>
> > use library 2.5 or use library 2.6 etc.

>
> > The 2 main things that the library management interface has to do is
> > intra library management and inter library management.

>
> > intra library mgmt- consider books to be different libraries
> > (standard, commercial, private, hobby, etc)
> > inter library mgmt- consider books to be modules inside a library
> > ( standard, commercial, private, hobby, etc)

>
> > if somehow we could accomplish this kind of mother of a all plugin/ad-
> > hoc system that is a real breakthrough.

>
> > Advantages:

>
> > 1. new modules can be added to the stream quickly
> > 2. let the user select what he want to do
> > 3. modules (that interdepend on each other) can be packed into small
> > distribution and added to the stream quickly without waiting for new
> > releases
> > 4. solution to problems like py 2.x and 3.x
> > 5. users can be up to date
> > 6. documentation becomes easy + elaborate to users
> > 7. bug managing is easy too
> > 8. more feed back
> > 9. testing also becomes easy
> > 10. many more , i don't know.. you have to find.

>
> > Python already has some thing like that __future__ stuff. but my
> > question is how many people know that? and how many use that? most of
> > them wait until old crust gets totally removed. that is bad for user
> > and python. that is why problems like py2.x py3.x originate. If there
> > is a newer book collection it must always be available at the library.
> > i must not go to another library to get that book.

>
> You are greatly oversimplifying things, and ignoring a *lot* of issues
> here. The reason for __future__ is that it can *break* things if new
> features were just introduced. Take the with-statement, reachable in
> python2.5 throug
>
> * *from __future__ import with_statement
>
> It introduces a new keyword, which until then could be happily used as
> variable name.
>
> So you can't arbirtarily mix code that is written with one or the other
> feature missing.
>
> Then there is the issue of evolving C-APIs (or ABI), wich makes modules
> incompatible between interpreters.
>
> And frankly, for most of your list I don't see how you think your
> "approach" reaches the stated advantages. Why is documentation becoming
> easier? Why bug managing? Why testing?
>
> I'm sorry, but this isn't thought out in any way, it's just wishful
> thinking IMHO.
>
> Diez


I don't know if you have used Dev-C++.<http://www.bloodshed.net/dev/
packages/index.html> It has a 'package management' mechanism for the
standard libraries.
please see the <http://devpaks.org/> webpage where all the packaged
libraries are stored.

In python we have the PyPI which is equivalent to the http://devpacks.org
but in PyPI the packages are mostly user made applications.
What I want is similar to PyPI but for the python standard libraries,
so that they (libraries) are as add-on as possible.
check this out too.. <http://molhanec.net/devcpphelp/packages.php>


I guess you understand what I am thinking... and do pardon my english
too..

--

Regards,
Sriram.

Diez B. Roggisch 11-12-2009 11:27 AM

Re: standard libraries don't behave like standard 'libraries'
 
Sriram Srinivasan schrieb:
> On Nov 12, 3:56 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
>> Sriram Srinivasan schrieb:
>>
>>
>>
>>> I guess why every programming language has some kind of a 'standard
>>> library' built in within it.
>>> In my view it must not be called as a 'library' at all. what it does
>>> is like a 'bunch of built-in programs ready-made to do stuff'.
>>> Lets see what a 'library' does:
>>> 1. offers books for customers
>>> 1.1 lets user select a book by genre, etc
>>> 1.2 lets user to use different books of same genre, etc
>>> 1.3 lets user to use books by same author, etc for different genre
>>> 2. keeps track of all the books + their genre
>>> 2.1 first knows what all books it has at present
>>> 2.2 when new book comes it is added to the particular shelf sorted by
>>> genre,author,edition, etc.
>>> 2.3 when books become old they are kept separately for future
>>> reference
>>> 2.4 very old books can be sent to a museum/discarded
>>> I guess no standard library does the minimum of this but wants to be
>>> called a library.
>>> As a python user I always wanted the standard library to have such
>>> features so the user/developer decides to use what set of libraries he
>>> want.
>>> consider the libraries for 2.5 ,2.6, 3K are all available to the user,
>>> the user selects what he wants with something like.
>>> use library 2.5 or use library 2.6 etc.
>>> The 2 main things that the library management interface has to do is
>>> intra library management and inter library management.
>>> intra library mgmt- consider books to be different libraries
>>> (standard, commercial, private, hobby, etc)
>>> inter library mgmt- consider books to be modules inside a library
>>> ( standard, commercial, private, hobby, etc)
>>> if somehow we could accomplish this kind of mother of a all plugin/ad-
>>> hoc system that is a real breakthrough.
>>> Advantages:
>>> 1. new modules can be added to the stream quickly
>>> 2. let the user select what he want to do
>>> 3. modules (that interdepend on each other) can be packed into small
>>> distribution and added to the stream quickly without waiting for new
>>> releases
>>> 4. solution to problems like py 2.x and 3.x
>>> 5. users can be up to date
>>> 6. documentation becomes easy + elaborate to users
>>> 7. bug managing is easy too
>>> 8. more feed back
>>> 9. testing also becomes easy
>>> 10. many more , i don't know.. you have to find.
>>> Python already has some thing like that __future__ stuff. but my
>>> question is how many people know that? and how many use that? most of
>>> them wait until old crust gets totally removed. that is bad for user
>>> and python. that is why problems like py2.x py3.x originate. If there
>>> is a newer book collection it must always be available at the library.
>>> i must not go to another library to get that book.

>> You are greatly oversimplifying things, and ignoring a *lot* of issues
>> here. The reason for __future__ is that it can *break* things if new
>> features were just introduced. Take the with-statement, reachable in
>> python2.5 throug
>>
>> from __future__ import with_statement
>>
>> It introduces a new keyword, which until then could be happily used as
>> variable name.
>>
>> So you can't arbirtarily mix code that is written with one or the other
>> feature missing.
>>
>> Then there is the issue of evolving C-APIs (or ABI), wich makes modules
>> incompatible between interpreters.
>>
>> And frankly, for most of your list I don't see how you think your
>> "approach" reaches the stated advantages. Why is documentation becoming
>> easier? Why bug managing? Why testing?
>>
>> I'm sorry, but this isn't thought out in any way, it's just wishful
>> thinking IMHO.
>>
>> Diez

>
> I don't know if you have used Dev-C++.<http://www.bloodshed.net/dev/
> packages/index.html> It has a 'package management' mechanism for the
> standard libraries.


No, it hasn't. It has packages for *additional* libraries. C++ has only
a very dim concept of standard-libraries. And those usually ship with
the compiler, as standard-libraries shipped with python.

> please see the <http://devpaks.org/> webpage where all the packaged
> libraries are stored.
>
> In python we have the PyPI which is equivalent to the http://devpacks.org
> but in PyPI the packages are mostly user made applications.
> What I want is similar to PyPI but for the python standard libraries,
> so that they (libraries) are as add-on as possible.
> check this out too.. <http://molhanec.net/devcpphelp/packages.php>


Why do you want that? What is the actual issue you are addressing?
Python's strength is that it comes with a certain set of libs bundled.
Artificially to unbundle them, forcing users to install them separatly
makes little sense, if any. Sure, updating a bug might be *slightly*
easier, but then the standard-libraries are well-tested and decoupling
their evolving from the releases of the core interpreter opens up a
whole can of worms of problems.

There is a tradeoff for both approaches, and one can argue if the
current balance is the right one - but if so, then over concrete
packages, not over the system in general.


Diez

Sriram Srinivasan 11-12-2009 11:28 AM

Re: standard libraries don't behave like standard 'libraries'
 
On Nov 12, 3:56*pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> Sriram Srinivasan schrieb:
>
>
>
> > I guess why every programming language has some kind of a 'standard
> > library' built in within it.
> > In my view it must not be called as a 'library' at all. what it does
> > is like a 'bunch of built-in programs ready-made to do stuff'.

>
> > Lets see what a 'library' does:

>
> > 1. offers books for customers
> > *1.1 lets user select a book by genre, etc
> > *1.2 lets user to use different books of same genre, etc
> > *1.3 lets user to use books by same author, etc for different genre

>
> > 2. keeps track of all the books + their genre
> > *2.1 first knows what all books it has at present
> > *2.2 when new book comes it is added to the particular shelf sorted by
> > genre,author,edition, etc.
> > *2.3 when books become old they are kept separately for future
> > reference
> > *2.4 very old books can be sent to a museum/discarded

>
> > I guess no standard library does the minimum of this but wants to be
> > called a library.

>
> > As a python user I always wanted the standard library to have such
> > features so the user/developer decides to use what set of libraries he
> > want.

>
> > consider the libraries for 2.5 ,2.6, 3K are all available to the user,
> > the user selects what he wants with something like.

>
> > use library 2.5 or use library 2.6 etc.

>
> > The 2 main things that the library management interface has to do is
> > intra library management and inter library management.

>
> > intra library mgmt- consider books to be different libraries
> > (standard, commercial, private, hobby, etc)
> > inter library mgmt- consider books to be modules inside a library
> > ( standard, commercial, private, hobby, etc)

>
> > if somehow we could accomplish this kind of mother of a all plugin/ad-
> > hoc system that is a real breakthrough.

>
> > Advantages:

>
> > 1. new modules can be added to the stream quickly
> > 2. let the user select what he want to do
> > 3. modules (that interdepend on each other) can be packed into small
> > distribution and added to the stream quickly without waiting for new
> > releases
> > 4. solution to problems like py 2.x and 3.x
> > 5. users can be up to date
> > 6. documentation becomes easy + elaborate to users
> > 7. bug managing is easy too
> > 8. more feed back
> > 9. testing also becomes easy
> > 10. many more , i don't know.. you have to find.

>
> > Python already has some thing like that __future__ stuff. but my
> > question is how many people know that? and how many use that? most of
> > them wait until old crust gets totally removed. that is bad for user
> > and python. that is why problems like py2.x py3.x originate. If there
> > is a newer book collection it must always be available at the library.
> > i must not go to another library to get that book.

>
> You are greatly oversimplifying things, and ignoring a *lot* of issues
> here. The reason for __future__ is that it can *break* things if new
> features were just introduced. Take the with-statement, reachable in
> python2.5 throug
>
> * *from __future__ import with_statement
>
> It introduces a new keyword, which until then could be happily used as
> variable name.
>
> So you can't arbirtarily mix code that is written with one or the other
> feature missing.
>
> Then there is the issue of evolving C-APIs (or ABI), wich makes modules
> incompatible between interpreters.
>
> And frankly, for most of your list I don't see how you think your
> "approach" reaches the stated advantages. Why is documentation becoming
> easier? Why bug managing? Why testing?
>
> I'm sorry, but this isn't thought out in any way, it's just wishful
> thinking IMHO.
>
> Diez


__future__ as you said helps in stop breaking things. what i suggest
that if both the libraries (in yr case-with is defined in one and
other with is not defined is a simple one) like py2.x and py3.x exists
and i want to use 3.x features in the morning then in the evening i
want to use 2.x or something like that just add on the library and i
get the require functionality

Diez B. Roggisch 11-12-2009 11:35 AM

Re: standard libraries don't behave like standard 'libraries'
 
Sriram Srinivasan schrieb:
> On Nov 12, 3:56 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
>> Sriram Srinivasan schrieb:
>>
>>
>>
>>> I guess why every programming language has some kind of a 'standard
>>> library' built in within it.
>>> In my view it must not be called as a 'library' at all. what it does
>>> is like a 'bunch of built-in programs ready-made to do stuff'.
>>> Lets see what a 'library' does:
>>> 1. offers books for customers
>>> 1.1 lets user select a book by genre, etc
>>> 1.2 lets user to use different books of same genre, etc
>>> 1.3 lets user to use books by same author, etc for different genre
>>> 2. keeps track of all the books + their genre
>>> 2.1 first knows what all books it has at present
>>> 2.2 when new book comes it is added to the particular shelf sorted by
>>> genre,author,edition, etc.
>>> 2.3 when books become old they are kept separately for future
>>> reference
>>> 2.4 very old books can be sent to a museum/discarded
>>> I guess no standard library does the minimum of this but wants to be
>>> called a library.
>>> As a python user I always wanted the standard library to have such
>>> features so the user/developer decides to use what set of libraries he
>>> want.
>>> consider the libraries for 2.5 ,2.6, 3K are all available to the user,
>>> the user selects what he wants with something like.
>>> use library 2.5 or use library 2.6 etc.
>>> The 2 main things that the library management interface has to do is
>>> intra library management and inter library management.
>>> intra library mgmt- consider books to be different libraries
>>> (standard, commercial, private, hobby, etc)
>>> inter library mgmt- consider books to be modules inside a library
>>> ( standard, commercial, private, hobby, etc)
>>> if somehow we could accomplish this kind of mother of a all plugin/ad-
>>> hoc system that is a real breakthrough.
>>> Advantages:
>>> 1. new modules can be added to the stream quickly
>>> 2. let the user select what he want to do
>>> 3. modules (that interdepend on each other) can be packed into small
>>> distribution and added to the stream quickly without waiting for new
>>> releases
>>> 4. solution to problems like py 2.x and 3.x
>>> 5. users can be up to date
>>> 6. documentation becomes easy + elaborate to users
>>> 7. bug managing is easy too
>>> 8. more feed back
>>> 9. testing also becomes easy
>>> 10. many more , i don't know.. you have to find.
>>> Python already has some thing like that __future__ stuff. but my
>>> question is how many people know that? and how many use that? most of
>>> them wait until old crust gets totally removed. that is bad for user
>>> and python. that is why problems like py2.x py3.x originate. If there
>>> is a newer book collection it must always be available at the library.
>>> i must not go to another library to get that book.

>> You are greatly oversimplifying things, and ignoring a *lot* of issues
>> here. The reason for __future__ is that it can *break* things if new
>> features were just introduced. Take the with-statement, reachable in
>> python2.5 throug
>>
>> from __future__ import with_statement
>>
>> It introduces a new keyword, which until then could be happily used as
>> variable name.
>>
>> So you can't arbirtarily mix code that is written with one or the other
>> feature missing.
>>
>> Then there is the issue of evolving C-APIs (or ABI), wich makes modules
>> incompatible between interpreters.
>>
>> And frankly, for most of your list I don't see how you think your
>> "approach" reaches the stated advantages. Why is documentation becoming
>> easier? Why bug managing? Why testing?
>>
>> I'm sorry, but this isn't thought out in any way, it's just wishful
>> thinking IMHO.
>>
>> Diez

>
> __future__ as you said helps in stop breaking things. what i suggest
> that if both the libraries (in yr case-with is defined in one and
> other with is not defined is a simple one) like py2.x and py3.x exists
> and i want to use 3.x features in the morning then in the evening i
> want to use 2.x or something like that just add on the library and i
> get the require functionality


This doesn't make sense to me. What are you doing in the morning, and
what in the evening, and to what extend is the code the same or are you
talking about different pieces of code?

Diez

Sriram Srinivasan 11-12-2009 11:54 AM

Re: standard libraries don't behave like standard 'libraries'
 
On Nov 12, 4:35*pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> Sriram Srinivasan schrieb:
>
>
>
> > On Nov 12, 3:56 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> >> Sriram Srinivasan schrieb:

>
> >>> I guess why every programming language has some kind of a 'standard
> >>> library' built in within it.
> >>> In my view it must not be called as a 'library' at all. what it does
> >>> is like a 'bunch of built-in programs ready-made to do stuff'.
> >>> Lets see what a 'library' does:
> >>> 1. offers books for customers
> >>> *1.1 lets user select a book by genre, etc
> >>> *1.2 lets user to use different books of same genre, etc
> >>> *1.3 lets user to use books by same author, etc for different genre
> >>> 2. keeps track of all the books + their genre
> >>> *2.1 first knows what all books it has at present
> >>> *2.2 when new book comes it is added to the particular shelf sorted by
> >>> genre,author,edition, etc.
> >>> *2.3 when books become old they are kept separately for future
> >>> reference
> >>> *2.4 very old books can be sent to a museum/discarded
> >>> I guess no standard library does the minimum of this but wants to be
> >>> called a library.
> >>> As a python user I always wanted the standard library to have such
> >>> features so the user/developer decides to use what set of libraries he
> >>> want.
> >>> consider the libraries for 2.5 ,2.6, 3K are all available to the user,
> >>> the user selects what he wants with something like.
> >>> use library 2.5 or use library 2.6 etc.
> >>> The 2 main things that the library management interface has to do is
> >>> intra library management and inter library management.
> >>> intra library mgmt- consider books to be different libraries
> >>> (standard, commercial, private, hobby, etc)
> >>> inter library mgmt- consider books to be modules inside a library
> >>> ( standard, commercial, private, hobby, etc)
> >>> if somehow we could accomplish this kind of mother of a all plugin/ad-
> >>> hoc system that is a real breakthrough.
> >>> Advantages:
> >>> 1. new modules can be added to the stream quickly
> >>> 2. let the user select what he want to do
> >>> 3. modules (that interdepend on each other) can be packed into small
> >>> distribution and added to the stream quickly without waiting for new
> >>> releases
> >>> 4. solution to problems like py 2.x and 3.x
> >>> 5. users can be up to date
> >>> 6. documentation becomes easy + elaborate to users
> >>> 7. bug managing is easy too
> >>> 8. more feed back
> >>> 9. testing also becomes easy
> >>> 10. many more , i don't know.. you have to find.
> >>> Python already has some thing like that __future__ stuff. but my
> >>> question is how many people know that? and how many use that? most of
> >>> them wait until old crust gets totally removed. that is bad for user
> >>> and python. that is why problems like py2.x py3.x originate. If there
> >>> is a newer book collection it must always be available at the library..
> >>> i must not go to another library to get that book.
> >> You are greatly oversimplifying things, and ignoring a *lot* of issues
> >> here. The reason for __future__ is that it can *break* things if new
> >> features were just introduced. Take the with-statement, reachable in
> >> python2.5 throug

>
> >> * *from __future__ import with_statement

>
> >> It introduces a new keyword, which until then could be happily used as
> >> variable name.

>
> >> So you can't arbirtarily mix code that is written with one or the other
> >> feature missing.

>
> >> Then there is the issue of evolving C-APIs (or ABI), wich makes modules
> >> incompatible between interpreters.

>
> >> And frankly, for most of your list I don't see how you think your
> >> "approach" reaches the stated advantages. Why is documentation becoming
> >> easier? Why bug managing? Why testing?

>
> >> I'm sorry, but this isn't thought out in any way, it's just wishful
> >> thinking IMHO.

>
> >> Diez

>
> > __future__ as you said helps in stop breaking things. what i suggest
> > that if both the libraries (in yr case-with is defined in one and
> > other with is not defined is a simple one) like py2.x and py3.x exists
> > and i want to use 3.x features in the morning then in the evening i
> > want to use 2.x or something like that just add on the library and i
> > get the require functionality

>
> This doesn't make sense to me. What are you doing in the morning, and
> what in the evening, and to what extend is the code the same or are you
> talking about different pieces of code?
>
> Diez



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


Diez B. Roggisch 11-12-2009 01:07 PM

Re: standard libraries don't behave like standard 'libraries'
 
>
> 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

Steven D'Aprano 11-12-2009 01:21 PM

Re: standard libraries don't behave like standard 'libraries'
 
On Thu, 12 Nov 2009 00:31:57 -0800, Sriram Srinivasan wrote:

> I guess why every programming language has some kind of a 'standard
> library' built in within it.
> In my view it must not be called as a 'library' at all. what it does is
> like a 'bunch of built-in programs ready-made to do stuff'.
>
> Lets see what a 'library' does:
>
> 1. offers books for customers

[...]


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.

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.


> As a python user I always wanted the standard library to have such
> features so the user/developer decides to use what set of libraries he
> want.
>
> consider the libraries for 2.5 ,2.6, 3K are all available to the user,
> the user selects what he wants with something like.
>
> use library 2.5 or use library 2.6 etc.


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.



--
Steven

Sriram Srinivasan 11-12-2009 01:43 PM

Re: standard libraries don't behave like standard 'libraries'
 
On Nov 12, 6:07*pm, "Diez B. Roggisch" <de...@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@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.




All times are GMT. The time now is 04:48 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.