jacobian.org

http://www.parallelpython.com/ is another way to get concurrency, although targetted at multiple core/cpu/machine scaling.

Numeric has been superseded (obsoleted?) by numpy (It appears that many people are not aware of this.)

I remember seeing a post by Guido about some of the modules that weren't in the standard library, but I don't have the link handy.

Part of his point, if I understood him correctly, about modules like BeautifulSoup and others is that they don't have names that indicate what they do, or that the names are just plain goofy. I may have misinterpreted what he said, but he did perceive the names as a problem.

It's a small point, but if that's part of what's keeping BeutifulSoup out of the standard library, it seems like a bit of a shame.

My (weakly informed) 2 cents.

CBT

5. You don't need interfaces in Python: names *are* interfaces and
that's a much better convention for an interpreter.

4. A list is a mutable collection, which is something different than
a tuple (an immutable collection) or an iterator.

3. If you need something more elaborated than asyncore but can't suffer twisted code, have a look at Allegra (yes this is a shameless plug ;-)

2. Use distutils, that's the standard.

1. If you want to add something to the Python Library, contribute it ...

Regarding your last item: I think many problems with the library have been errors of comission, rather than omission -- "batteries included" notwithstanding. Witness the longevity of regex, soundex, and some of the Sun audio code through the years. It's much easier to add a module to stdlib than to remove it, and weaknesses in the library tend to get reflected (often unjustly, IMO) on the language itself.

-Jeff Bauer

Regarding threading, I'd love to see something like Plan 9's Alef's channels as a means of communication and synchronisation between Python "threads". They're far easier to program and reason about that mutexes, semaphores, etc. Perhaps py Lib's "greenlets" would be a suitable thing to build them on, leaving OS threads for blocking actions.

http://swtch.com/~rsc/thread/
http://codespeak.net/py/dist/greenlet.html

1. Slower than java.
2. Limited expressiveness. No multiline anonymous closures like in ruby. Guido stated that this it is syntactically impossible. Not nearly as DSL or macro friendly as other languages.
3. self self self self - it's as if OOP was just tacked on.
4. Redundant or meaningless symbols and keywords like the colon at the beginning of a block, and all the underscores. What is "def"? Why "elif" instead of "else if"? "lambda"?
5. The python community. RTFM jerks, rude to all newbies or new ideas. Zealots about python (Guido called them the NIMPY crowd: not in my python), and they spread absolute FUD about everything else. Shot down most proposals for python, including ones Guido has proposed himself, like optional static typing or case-insensitivity. If you don't want python to ever change, stick with python 1.5 or whatever version you are holding on to.

Die python die.

"Not sure what Java's one good idea would be."

The sandbox maybe; none of that buffer p0wning crap.

Oh, all right then:

5: self

4: __

3: not knowing a function's argument types. I think that means I'm in the "would like optional type declarations" camp.

2: bytestrings (they suuuuucccckk).

1: GIL. But concurrency sucks everywhere. Java sucks a bit less as long as you make sure to use queued comms; which is a poor man's actor/message passing. Ruby is also a joke. Hence I'm off to muck about with Erlang; I figure the time spend not dealing with livelocks and scaling can be poured in porting 30 or so libraries. And omigod Erlang has *headed lists*. Closures and continuations? Pfft.

Sorry, but your point #2 really looks weak. When you compare how python handles libraries (source included in each and every lib, in a zipped archive) to any other languages, well... java has these compiled funny things called .class, hidden in never-ending directory structures inside a zip file; DLLs are as transparent as mud; and I bet that you won't do much of a "view source" with C libraries :)

I'd say python eggs manage to integrate the best of two worlds (using compression and maintaining full source). How would you change it?

The problem with import I/O is real but it's a different matter, and it's shared by pretty much any comparable environment. Again, there is no easy answer.

@karl

I couldn't agree more with your points 1 and 2, Python really needs to have a much richer collection of documentation, but you are crazy for thinking 3 and 4 are problems, there is not a single thing to improve about Python documentation.

Could you enlighten an outsider? What the heck is the point of an interface in a dynamic language? I always thought the point of an interface was to keep your static typechecker happy. As long as the object implements the methods you need, isn't it all good?

Maybe it puts a little more burden on the documentation, but if you want your language to provide type documentation for you, there are plenty of statically-typed languages in the world. Why add a language feature that has no functional effect whatsoever?

Of course I've been messing with smalltalk lately and maybe that warps my perspective, but I just don't get it.

In Python 2.5, pydoc and pdb work correctly with eggs (and other zipfiles).

Also, your information about sys.path is incorrect. If you install zipped eggs, there is no extra stat'ing that takes place; Python since 2.3 caches zipfile directories in the zipimport module, so no system calls are needed to check the importability of something from a zipped sys.path entry, once the initial read of the zipfile is done (which happens the first time an import tries to look at the zipfile.

Finally, if you want source, use e.g.:

easy_install -eb. FooBar

and you'll get a nice './foobar' directory with the package's original (pre-egg) source. (The -e is short for --editable.)

I've only used zope.interface in Python, but I quite like it. zope.interface declarations make excellent reference material when you are trying to use software that someone else wrote.

I don't think "feels clunky" is a valid critique of zope.interface. Alhtough I might apply the "feels clunky" critique to zope.interfaces use of camelCase methods as opposed to under_score methods.

@joe

Interfaces in a dynamic language can be thought of as a formal way of describing what methods an object is supposed to implement. The statement "As long as the object implements the methods you need, isn't it all good?" only holds true if you know *what* to implement.

In addition, if you want to perform an action based on the type of an object, interfaces can make that kind of code much more concise. For example, if you want to do one thing if your object only implements getFoo and getBar, but another thing if it additionally implements setFoo and setBar, you could end up writing a fairly lengthy set of conditional statements. With interfaces you could write something like:

if IFooReader.providedBy(object) and IFooWriter.providedBy(object):
# do stuff
elif IFooReader.providedBy(object):
# do other stuff
else:
# raise an error

> Hmmm. Is that effbot being sarcastic or is it really Doug Holton?

It's Doug, who else.

Booooo.

"""With interfaces you could write something like: [snip]"""

Please, don't. Interface introspection creates code that is closed to extension. Have you ever tried creating objects that work correctly when pydoc tries to document them, for example? [shudder] Interfaces without adaptation are an accident waiting to happen, and pydoc is a good example of why if-thens based on interfaces are evil.

See these three posts for a full explanation, including why interfaces end up being helpful in Java in a way that they won't in Python (and no, it's not about multiple inheritance):

http://mail.python.org/pipermail/python-3000/2007-March/006206.html
http://mail.python.org/pipermail/python-3000/2007-March/006232.html
http://mail.python.org/pipermail/python-3000/2007-March/006244.html

My thoughts:

- Explicit interfaces impose undue inflexibility in the language. Maybe what you are looking for is more along the lines of published standards (e.g. DB-API 2 or WSGI). If you are looking for executable documentation, there's no functional difference between interfaces and ABCs (though since Python supports multiple inheritence it seems silly to not use it for ABCs).

- I much prefer having a CPAN-esque approach to including modules. Python the language and standard library can move slowly, whereas specific packages such as PIL, SciPy, or SOAPpy can move at their own pace. I'm actually typically surprised whenever I discover new modules installed by default (makes me wonder what else is installed under my nose).

- I agree with concurrency being a problem, with the GIL. I've had my share of Twisted programming and I absolutely hate it.

Adding things that I don't like about the language myself:

- __ for private

- no obvious way to declare member variables. I just define them all in my constructor, but I like being able to see the structural definition of an object without having to examine the behavior.

- unicode is difficult to "get right" for a beginner, and relevant documentation is rather lacking

- os.exit() doesn't do what you'd expect in anything but the main thread (it raises SystemExit, which only kills the program if raised in the main thread)