merits of Lisp vs Python

Paul Boddie paul at boddie.org.uk
Sun Dec 10 16:11:53 EST 2006


hit_the_lights wrote:
>
> I should have added some lines:
>
> ==== python ====================
> >>> import a
> >>> import b
> You sucker thought I'd import b for you.
> Instead I'm going to erase your hard drive.
> >>> a
> <module 'a' from 'a.pyc'>
> >>> b
> >>>
> ==============================
>
> I was suprised that b was defined at all.

Well, I've done all sorts of things with Python's import machinery, and
I'd prefer not to stare too long at its implementation, but both import
statements by their very nature in Python are still import statements.
Of course you can always argue that some undesirable effect of
redefining the keyword via a macro is also achievable by misusing the
import machinery, that both things are therefore just as dangerous, and
that macros are inherently no more dangerous than exposed library
mechanisms employed by the virtual machine. I'd agree generally with
that reasoning, and you can see in various features of Python that lots
of covert side-effects can be introduced which would prove surprising
to the casual developer when he or she uses some seemingly harmless
construct. (Interestingly, some of the newer features in Python could
have been introduced using macros, and perhaps EasyExtend already
demonstrates this.)

Ultimately, I think that the main point of contention is little to do
with macros or their absence from Python. Instead, it's more about
people coming to an agreement about form and behaviour guarantees for
Python programs - in other words, what you can expect when you open a
Python source file and start reading the code. It should be noted that
attitudes are generally negative towards careless redefinition of
fundamental or common concepts or mechanisms of the language, just as I
imagine it would be with Lisp, and one only needs to consider reactions
to various Ruby-related advocacy to see where the many in the Python
community supposedly draw the line at things like pervasive
monkey-patching of built-in classes. To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.

Paul




More information about the Python-list mailing list