Python For Lisp Programmers

"Python for Lisp Programmers" by PeterNorvig. Available at http://www.norvig.com/python-lisp.html

paraphrased somewhat from the site ...

: This is a brief introduction to PythonLanguage for LispLanguage programmers. Basically, Python can be seen as a dialect of Lisp with "traditional" syntax (what Lisp people call InfixNotation). Python supports all of Lisp's essential features except macros, and you don't miss macros all that much because it does have eval, operator overloading and regular-expression parsing, so you can create custom languages that way.

and

: Python can be seen as either a practical (better libraries) version of SchemeLanguage, or as a cleaned-up (no $@&%) version of PerlLanguage. While Perl's philosophy is TIMTOWTDI (or TimTowTdi - there is more than one way to do it), Python tries to provide a minimal subset that people will tend to use in the same way. One of Python's controversial features, using indentation level rather than begin/end or {/}, was driven by this philosophy: since there are no braces, there are no style wars over where to put the braces. Interestingly, Lisp has exactly the same philosophy on this point: everyone uses emacs to indent their code. If you deleted the parens on control structure special forms, Lisp and Python programs would look quite similar.

Much more evidence and several examples are given on the site, and while many will feel (with some justification) that the case is being overstated, it seems convinving that there are strong similarities, although there are significant differences.

'Specific points of disagreement ...

Python's lambda doesn't allow conditionals, a side effect of Python making a distinction between expressions and statements. This is far more than sufficient to prevent Python from being any kind of Lisp dialect; it just owes (and acknowledges) homage to Lisp.

Nor does python have a useful form lambda. Python's implementation of lambda is limited to a single expression, virtually crippling it. Python is much more a diluted form of SmalltalkLanguage, than lisp. RubyLanguage is a more powerful, more Smalltalkie Python.

I like Python as much if not more than the next bloke but Python is no substitute for Lisp or Scheme. Try extending the syntax of Python or using closures or any of the various 'meta' tricks that Schemers consider essential and the difference quickly becomes painfully obvious.

''Not to mention, any comparison to scheme is laughable, given GuidoVanRossum's attitude towards tail recursion:

"I don't like reading code that was written by someone trying to use tail recursion. It's the ultimate code obfuscation." --GuidoVanRossum

(posted to the python-dev mailing list recently, during a discussion of a possible imlementation of TailCallOptimization [to cut a long story short, guido says: No.])''

GuidoVanRossum is thinking of eliminating Python's lambda, map(), filter(), and reduce() in the coming years. He says in his blog dated March 10, 2005 (http://www.artima.com/weblogs/viewpost.jsp?thread=98196), "About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. But, despite of the PR value, I think these features should be cut from Python 3000..." He expects tons of disagreement "all from ex-Lisp-or-Scheme folks."

For backward-compatibility, they are probably stuck there for good or bad. Python cannot pull a Microsoft.NET without a uprising.

Dropping lambda. I don't think that's actually what he's doing. He's dropping one of two syntax for lambdas. The second is the normal 'def func(a,b,c): yada; yada; yada' syntax. Notably, the result of the def is a variable containing an anonymous function. Given the previous def, 'myFunc = func' works as expected, because the function behind 'func' has no knowledge of the name assigned to it. Given python's philosophy of providing one and only one way of doing something (when practical), it makes sense.

--WilliamUnderwood

CategoryPython, CategoryLisp