Toward Python's future article

[Steven Bethard]

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