Ville Vainio said:
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