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

Douglas Alan doug at alum.mit.edu
Wed Jun 20 17:23:42 EDT 2007


Steven D'Aprano <steven at REMOVE.THIS.cybersource.com.au> writes:

> All of which makes Douglas Alan's accusations of Not Invented Here 
> syndrome about Python seem rather silly.

I've never made such an accusation about Python itself -- just about
the apparent attitude of some pontiffs.

> The point I was making isn't that Scheme/Lisp features are "bad",
> but that there is no reason to slavishly follow Scheme just because
> it is(?)  technically the most "pure" programming language.

I don't argue in favor of purity.  I argue in favor of functionality
that would help me write better programs more easily.

Having a somewhat pure and minimalistic core language, however,
probably does help to make a language easier to implement, maintain,
and understand.

> I'm glad somebody understands lambda calculus and closures and meta-
> classes, and that those people have created Python so I don't have
> to.  And I suspect that for every Douglas Alan enamored with Scheme,
> there are ten thousand programmers who just want to use a handful of
> pre-built tools to get the work done, never mind using macros to
> create the tools they need before they can even start.

I don't typically want to write that many macros myself.  I want to be
part of a community where cool macro packages are actively developed
that I can then use.  For instance, in Common Lisp, the entire OO
system is just a big macro package that was implemented entirely
within the language.

With macros and first class continuations, as Sussman points out in
his essay, people can then implement very interesting features like
backtracking.  Again, I don't want to implement a backtracking macro
package myself; I want to be able to use what the community might come
up with.

> But "Scheme has macros" isn't a justification for why Python should
> have them.

No one ever gave that justification.  The justification is that they
are *good*.

Macros are a way to abstract syntax the way that objects are used to
abstract data types and that iterators and generators abstract
control, etc.

|>oug



More information about the Python-list mailing list