Why is Python popular, while Lisp and Scheme aren't?

Michael Hudson mwh at python.net
Wed Dec 4 07:32:39 EST 2002


Courageous <jkraska at san.rr.com> writes:

> Ah. Well, the "clean room" phrase is so charged with meaning, and I'm really
> misusing it. Would "I was writing my own python-ish lexer and parser for my
> own amusement sake be more clear"? :)

I understood what you meant, I think.

> I really wanted to face each lexing and parsing decision from afresh,
> and face all the same problems a language designer would face without having
> a corpus of prior art. Occasionally, I'll opine that some decision the python
> designers made was the "natural solution to the problem, given the constraints
> of the type of language they chose." This is because I've encountered the problem
> personally, while trying to do it myself, and learned the nature of the "problem
> of Python" against the possible solution space of interpreter design.

Indeed, there's nothing like trying to implement something (or prove a
theorem, for that matter) for giving understanding of how it was done
in the first place.

> As for using the actual C-Python interpreter itself, I have some complaints about
> its internal modularity. It suffers from its lack of having been written in an
> OO language, IMO. 

Hmm.  I'd certainly agree there are bits of CPython that are pretty
horrible (the parser generator, the compiler, import.c, ...).

> Or to put it another way, there are (or were a year or two
> ago) cases of internals that were done one way that would have been done another,
> cleaner way had the language been implemented in an OO language.

They would probably be done a cleaner way if they were reimplemented
in C today.  The incomprehensible bits of CPython are usually the
oldest (for at least two reasons).

> Although, don't get me wrong on that: the Python internals are remarkably OO
> given they're done in a non-OO language.
> 
> This was a long winded way of saying that I wanted all internals in C++.

Hmm, again.  There are a very short list of things I'd like to import
from C++, I think.  Being able to cast from (eg) PyTypeObject* to
PyObject* without a cast would be nice.  Not having to declare
variables at the start of a block.  Some more code could be shared
between strings and unicodes by using templates, maybe.

I think I'd have _severe_ reservations about using much more of C++
than that.  Making (eg) nb_add a virtual function would be an
appalling idea, for instance (there goes subtyping in Python...).

If I were starting again, I guess a _very_ restricted C++ would be an
implementation language I'd consider.  I doubt Guido would.

Cheers,
M.

-- 
  In many ways, it's a dull language, borrowing solid old concepts
  from many other languages & styles:  boring syntax, unsurprising
  semantics, few  automatic coercions, etc etc.  But that's one of
  the things I like about it.                 -- Tim Peters, 16 Sep 93



More information about the Python-list mailing list