Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Toward Python's future article

Reply
Thread Tools

Toward Python's future article

 
 
daniel narf
Guest
Posts: n/a
 
      10-07-2004

Hi i am sure most of you have read the article of Andrew Kuchling about focusing
more in the standart library than language newFeatures/tweaking and probably i
as many others would like to know what the python hackers/developers think about
this proposal.Maybe this post is out of place but oh well..

i am personaly very interested in improving the stdlib which is very messy in my
opinion right now.

the article(several comments):

http://www.amk.ca/diary/archives/cat_python.html#003382

 
Reply With Quote
 
 
 
 
GerritM
Guest
Posts: n/a
 
      10-07-2004
"daniel narf" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
>
> Hi i am sure most of you have read the article of Andrew Kuchling about

focusing
> more in the standart library than language newFeatures/tweaking and

probably i
> as many others would like to know what the python hackers/developers think

about
> this proposal.Maybe this post is out of place but oh well..
>

In general the article makes a lot of sense to me. I don't have any voting
rights myself, since I have never contributed to the development myself. So
my comments are from the users viewpoint.The strong point of Python is the
combination of a simple, clear, and well-structured language, with a
well-filled toolbox in the standard lib, and of course a high quality
implementation, running out-of-the-box. The standard lib seems to develop
relatively slower than the other elements (language and quality of
implementations). Andrew indicates many examples where the standard lib can
be further improved.

I disagree with one statement: the required involvement of Guido. I do think
that the standard lib also needs a BDFL who takes final decisions based on
good intuition and insight, balancing elegance and pragmatism. A standard
lib without clear concepts becomes a box of Pandorra.

> i am personaly very interested in improving the stdlib which is very messy
> in my opinion right now.
>

No, it is not very messy. Yes, there is legacy of long time evolution. But
compared to real messy systems the Python standard lib is still very well
structured

regards, Gerrit Muller
--
Gaudi systems architecting:
<http://www.extra.research.philips.com/natlab/sysarch/>

Praktijk voor Psychosociale therapie Lia Charité
<www.liacharite.nl>





 
Reply With Quote
 
 
 
 
Ville Vainio
Guest
Posts: n/a
 
      10-07-2004
>>>>> "daniel" == daniel narf <(E-Mail Removed)> writes:

daniel> Hi i am sure most of you have read the article of Andrew
daniel> Kuchling about focusing more in the standart library than
daniel> language newFeatures/tweaking and probably i

Tweaking/optimizing the interpreter is all right IMO. Language
features, esp. genexps are welcome too. I'm still not sure whether we
are at the local maximum yet.

Actually, what I'd like to see is (with a strong FWIW disclaimer, of
course):

1. Stabilize the language for Python 2.x series.

2. Start thinking about the important stuff that will go into py3.0 -
especially the major design issues like optional type declarations
that will pay off in products like IronPython.

3. Collect lots of "best of breed" stuff in a psedo-official "extra
batteries" distribution. This should include useful and
API-stable-ish frameworks. Some of the current standard libraries
could be moved to the extra batteries.

4. Publish a canonical type inference system for Python source code,
implemented in Python of course.

5. Put some effort in maturization of pydev+eclipse, making it the
"obvious" choice for the freeloaders who still want a mature IDE.

Yes, point 5 has very little to do with python standard libraries,
just something that would accelerate corporate penetration among the
uninitiated programmers, and is tightly mingled with point 4.

daniel> i am personaly very interested in improving the stdlib
daniel> which is very messy in my opinion right now.

I'm kinda surprised about the negative press the stdlib has been
getting as a result of AMK's blog entry. I still think stdlib is
beautiful .

daniel> the article(several comments):

daniel> http://www.amk.ca/diary/archives/cat_python.html#003382


--
Ville Vainio http://tinyurl.com/2prnb
 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      10-08-2004
Ville Vainio <ville <at> spammers.com> writes:
>
> Tweaking/optimizing the interpreter is all right IMO. Language
> features, esp. genexps are welcome too. I'm still not sure whether we
> are at the local maximum yet.


I agree.

I also support some somewhat more substantial language changes that I think
should happen in Python 3000 when iterators become the standard (instead of
lists). Things like evaluating function arguments as iterators instead of
converting them to a tuple first. (Without this, something like zip(*) will
read all the tuples in an iterator of tuples into memory before you even look
at the elements from the first tuple.) My suspicion is that even after Python
3000, we'll still run into language changes that we want, though I think the
frequency with which these changes are requested will continue to decrease.
It's one of the things that I've always liked about Python -- it's not afraid
of a little change if that makes code cleaner and/or easier to write.

> 5. Put some effort in maturization of pydev+eclipse, making it the
> "obvious" choice for the freeloaders who still want a mature IDE.


Yeah, it would be nice if there was one "obvious" IDE choice. Anyone wanna
bet on the day of the next post that asks why there aren't any good Python
IDEs?

> I'm kinda surprised about the negative press the stdlib has been
> getting as a result of AMK's blog entry. I still think stdlib is
> beautiful .


While one of the things I like most about Python is it's outstanding stdlib, I
wouldn't say that it's beautiful. There are some changes I'd like to see:

* Put the bisect, collections, heapq and Queue into a collections module (and
remove sets module since sets are now builtin)
* Put glob, os, shutil and popen2 into an os module
* Put getopt and optparse into an opt module (or remove getopt?)
* Put urllib and urllib2 into a urllib module

These happen to be the modules I use frequently, so the fact that they're not
as well organized as I might like is more obvious to me than would be for
other modules. But I assume that others who use other modules have also seen
similar trends.

Oh, and it would also be nice if all the modules followed the PEP 8 style
guide for naming -- it would decrease the confusion about what exactly the
suggested naming style *is*. I know I was confused about this because of the
stdlib until I found PEP 8.

Steve

 
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
Article on the future of Python Mark Lawrence Python 129 09-29-2012 03:07 AM
Re: Article on the future of Python Michael Harleman Python 0 09-25-2012 10:51 AM
CAN I COUNT 70-305 TOWARD BOTH MCSD AND MCDBA? IGNACIO DE LA TORRE MCSD 1 04-29-2004 11:35 AM
Will 70-216 Count Toward My MCSA? Jim Bayers MCSE 2 01-26-2004 08:16 PM
My future Python IDE article David Mertz Python 41 09-13-2003 02:25 PM



Advertisments