Toward Python's future article

[daniel narf]

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

 

[GerritM]

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>

 

[Ville Vainio]

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

 

[Steven Bethard]

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