The massive hype machine behind Java?

I do know that one complaint offered about the Python Library is that the 'standard' library is smaller than the Java libs -- corresponding packages are always available where there are holes between Java and Python's offerings (usually more than one competing package) but you're required to spelunk around the Vaults of Parnassus or SourceForge, and it's sometimes a crapshoot as far as quality or support go. I looked at every available SOAP library for Python a few months back, and every one of them seemed to be in some sort of disarray.

I know that some have called for a halt in changes to the language in favor of growing and polishing the standard lib -- perhaps it's time for a separate group besides the core developers to step up to this challenge (watch me as I take two steps backwards now...)

I have consistently heard the Open Source complaint of "too many & too unfinished" libraries. Particularly with Java and a bit with CPAN. I had hoped Python did not have this downfall, also.

Do you expect Python's Python Package Index venture should help this? http://www.python.org/pypi

SOAP is an excellent example. DotNetters looking to Python as a testing framework (or glue for components) with SOAP may, like me, find themself lost or needing to build custom solutions. Note: I also haven't looked since the early days of VS.Net, when there wasn't a Python equivilent of "Point and a WSDL to build a prooxy class" solution. Note: XML-RPC in DotNet has the external library obscurity problems.

The need for more library patches reviews, testing and documentation is definite. More folks need to come out of the woodwork, or, like you say, a shift from new features to standard lib.
This lurker also takes a step back. :-)

Hmm... I agree about the hype machine. But it's still the case that Java has a lot of library support that Python lacks, most of it provided by other venders who consider "java support" necessary, but probably haven't even heard of Python.

For instance, my current project is using a jdbc driver to access a Mumps database. I certainly don't know of any database api wrapper for mumps in Python.

OTOH, if we were using Python on this project then I could *write* a Mumps adapter in the time I would save just typing out loops! And since the Mumps jdbc driver we're using is a complete piece of junk which doesn't conform to the jdbc specs, I certainly wouldn't do a WORSE job.

I don't know a lot about Java. I swing between learning a bit more about it and being pissed off at the static typing and the exceedingly verbose syntax to such an extent that I put it away again for another few weeks/months.

Therefore I can't comment on its standard library other than to say whenever I've needed to delve into it I get the opinion that the scope is roughly similar to Python.

It is true that there are good and bad extensions to both libraries out there, but you pays your money and you takes your choice.

A few points on the other comments in this thread;

Python 2.3 is concentrating on small language changes and is focussed more on library bug fixing and performance enhancement (of both the language core and the standard library). In particular there is a new logging module, a new option parsing module and support for importing zipped up modules. The move towards type/object unification also continues in this release (for any Ruby fans still reading). For more information check out http://www.python.org/doc/2.3b1/whatsnew/.

The package index and metadata is a step towards a CPAN-like approach to *extensions* to the standard library. As ever with Python it is undertaken as a series of small steps and so should really blossom in the next year or so (but don't quote me on that). Anyway, Simon's original comment only covered the standard library I believe, not really obscure stuff like scary old databases on VAX/VMS systems. Mumps? Good lord I haven't come across that since the 1980s. By the way, if there is an ODBC adapter for your data source you can get to it through Egenix's mxODBC driver http://www.egenix.com/files/python/mxODBC.html.

If you want SOAP support in Python try the SOAPy module (http://soapy.sourceforge.net/). It hasn't been updated recently but I use it every day and haven't found a problem with it yet. Of course, YMMV ;-)

That said, I'll get me coat.

It's certainly true that there are often competing packages around, but I think that's true in the Java world also. How many MVC packages are there, (Struts, Webworks, ...) how many templating engines, (JSP, Velocity, ...) how many object relational mappers, you name it. This can be seen as either a good thing, or a bad one, but I don't see Java and Python differing too much on this score.

Proprietary support, though, is a good point. Until Python is as popular as Java, (which will almost certainly never happen, though it *should*) Pythoneers will just have to stick with generic drivers.

Andy points out a good SOAP library, and also mentions mxODBC. so getting at Mumps (whatever *that* is) should be doable.

The problem with the Java movement is that they seem hell-bent on inventing new APIs. JAXM (the official SOAP API) is a good example of this - it implements a DOM-like API which isn't compatible with the DOM (unless you use various implementation-specific hacks to get the underlying DOM elements). What the ____ were they thinking?!

Actually, on the subject of SOAP, unless you really want that feeling of remote procedure calls (which is actually a pretty blinkered view of what SOAP is all about, in my opinion), you'd be better off using the various XML and HTTP libraries for Python. Perhaps someone will "make it nice" at some point, or perhaps they already have.