Python's Lisp heritage

[Andrew Dalke]

James J. Besemer:
>Seems to me the more prominent genetic similarities are the overall
> semantics: late binding, garbage collection, lists and sequences as
> a way of life.

Those are also present in Perl, Tcl, Smalltalk, APL, Mathematica,
and many other languages.  Yes, Lisp was there first, but it's only an
indirect influence on Python.

>  Also, the fact that functions are values that may be free rebound
> to other names.

And Perl and Tcl and ...

>The semantics of and/or are rarely encountered outside of lisp and
> derivatives.

As far as I am aware, that may be true.  I know of no language besides
Python which does that.

>  MAP, APPLY, and especially LAMBDA also are pretty unique to Lisp.
>  This is VERY like Lisp and very UNLIKE "Algol like" languages.

I first learned about map through Perl.  That's also where I learned
about anonymous functions, although Perl doesn't use the word 'lambda.'

They were added to Python just before the 1.0 release, as a contribution
by someone other than Guido.  He's noted for saying way back in 1994
] To be honest, I wish I hadn't introduced lambda, map, filter and
] reduce -- they support a style that is inconsistent with the rest of
] Python. ...

One long-time complaint about them is that they weren't lisp-like
enough, for example, in how lambda handles scope.  Python used to
be quite different than Lisp in how it did static scope.  But as I
recall, others have pointed out that some lisp handle scoping
differently than others, and closer to how Python does it.

BTW, the first two features are best done in modern Python using
list comprehensions and the f(*a, **kw) syntax.

> Perhaps some of the Lisp heritage slipped in via ABC or via proposals
> from others without Guido's knowledge.

Oh, I believe there's a lot of indirect influence on Lisp on Python,
just as there is on most every other language.  Even the first language
I wrote (a BASIC written in BASIC) likely had some influence from Lisp,
and that was before I knew the language existed.

I just argue that there are few direct influences.

>> If there was lisp heritage, why isn't there anything like car/cdr?
>
>Easy.  Some things got left out.  They're not the SAME language.
>
>List indexing and and slices are better and more powerful, an important
> step forward.
  ...
> The more important LANGUAGE abstraction is that dotted pairs can be
> formed into lists and lists may be manipulated at a higher levels, and
> this same abstraction exists in Python.

I think you misunderstood my statement, but then again, I wasn't
very clear.  Lisp's idea of lists is as a composition of pairs.  As
such, certain operations like list indexing are (usually) slow, while
list mutation is fast.  On the other hand, Python uses a contiguous
block of memory, so indexing is fast but mutation (other than append)
is usually slow.

So algorithms which might run fast under Lisp do not under Python,
and vice versa.  The decision for this difference was made after
observations in ABC that most list use was through indexing, and not
through a direct decision to be different from Lisp.

>> ] Python comes from the Algol family of languages.
>
>In syntax yes.  In semantics it seems quite the opposite.

I've heard the statement from Lisp people that all other languages
are an attempt to reproduce Lisp, badly.

>> ] Common Lisp and Scheme.
>> ]
>> ] These languages are close to Python in their dynamic semantics,
>
>Which was my point.

You said Python was a "Lisp derivitave" with the use of len(obj)
based in "precedent dating back to the original language."  You
also said "Python claims a Lisp heritage."

I am not attempt to say that Python and Lisp don't have similar
semantics.  What I am saying is that these specific points you
made are not correct.  Python isn't a Lisp derivative, except in
the sense that all modern languages have Lisp influence.

And that's not the sense you mean since you said "So from a linguistic
heritage standpoint, it's actually rather odd that Python lacks
some equivalent of Scheme's IF."

> I don't agree.  I think syntax and semantics are almost orthogonal,
> with syntax being the less complicated, less important of the two.
> The fact that Python and Scheme have similar semantics make them very
> similar despite dramatic differences in their outer appearance.

Spoken, by the way, like a Lisp programmer.  I found that language
almost impenetrable because of the syntax and my several attempts to
learn the language have failed.  I enjoy Python's semantics, which
implies at least to me that syntax is very important.  Perl and Python
classes also have similar semantics -- Perl got them from Python --
but I couldn't figure out how to do OO programming in Perl because
the syntax was so cumbersome.

But I think you and I agree here, by your saying
>Other than that, I think it's widely acknowledged that Lisp's lack of
> syntax is a disadvantage for most applications.

> How'd [map, apply, lambda] get in there in the first place?  MAP?
> APPLY? EVAL?  They're not in ABC or any other "Algol language" that
> I'm aware of.

As mentioned above, 3rd party contributions which were never part of
the original plan for Python.  Perl has a 'map.'  Tcl has an 'eval'.
Others in this thread point out that functional languages like Clean
and Haskell have map, apply, and lambda.

C doesn't need an apply because it comes for free as part of the syntax.

> And since I was mistaken about the historical asides, my suggestions
> about inline choice and len() are blithely ignored.

I didn't reply on that because I thought other posters covered that
topic reasonably well, and I have very little to contribute in that regard.

The only this I can add is that after watching many non-programmers
(biologists, chemists, and physicists) learn Python, *none* have
complained to me that list.len() doesn't work.

Instead, since your commentary is at least partially based on a
view of history which is incorrect, I decided to comment on that
instead.

I could also have pointed out that except for metaobjects (which in Python
comes more from a Smalltalk heritage) the way Python has done classes
has effectively not changed in the last 10 years, so another statement
you made
> over time Python has increasingly placed much greater emphasis on Objects
is suspect.  But I don't have a firm understanding of the history of
that aspect of Python's history to back up my belief.  Neither, I
believe, do you.

                    Andrew
                    dalke at dalkescientific.com