Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> Andy Freeman <anamax at earthlink.net> writes:

>> Compare that with what a programmer using Python 2.4 has to do if
>> she'd like the functionality provided by 2.5's with statement.  Yes,
>> with is "just syntax", but it's extremely useful syntax, syntax that
>> can be easily implemented with lisp-style macros.

> Not really.  The with statement's binding targets all have to support
> the protocol, which means a lot of different libraries need redesign.
> You can't do that with macros.

But that's a library issue, not a language issue.  The technology
exists completely within Lisp to accomplish these things, and most
Lisp programmers even know how to do this, as application frameworks
in Lisp often do this kind.  The problem is getting anything put into
the standard.  Standardizing committees just suck.

I just saw a presentation today on the Boost library for C++.  This
project started because the standard library for C++ is woefully
inadequate for today's programming needs, but any chance of getting
big additions into the standard library will take 5-10 years.
Apparently this is true for all computer language standards.  And even
then, the new standard will be seriously lacking, because it is
usually based on armchair thinking rather than real-world usage.

So the Boost guys are making a defacto standard (or so they hope)
library for C++ that has more of the stuff you want, and then when the
standardizing committees get around to revising the actual standard,
the new standard will already be in wide use, meaning they just have
to sign off on it (and perhaps suggest a few tweaks).

Alas, the Lisp standards are stuck in this sort of morass, even while
many implementations do all the right things.

Python doesn't have this problem because it operates like Boost to
begin with, rather than having a zillion implementations tracking some
slow moving standard that then mandates things that might be nearly
impossible to implement, while leaving out much of what people need.

But then again, neither do many dialects of Lisp, which are developed
more or less like Python is.  But then they aren't standards
compliant, and so they don't receive wide adoption.

> Macros can handle some narrow special cases such as file-like
> objects, handled in Python with contextlib.closing.

Macros handle the language part of things in Lisp perfectly well in
this regard.  But you are right -- they certainly can't make
standardizing committees do the right thing.

|>oug