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