[Types-sig] Core Python.... (less is more)

Paul Prescod paul@prescod.net
Wed, 12 Jul 2000 17:44:59 -0500


neelk@cswcasa.com wrote:
> 
> ...
> 
> But if these *do* become real classes, then it won't be
> possible to ignore the OO nature of Python in the core
> language.[*]

Let me play the devil's advocate fromt the point of view of tools I
could use myself.

Should Daniel really define "core Python" or "a small, optimizable
Python subset." The former is probably more interesting to his thesis
advisor as a really challenging problem, but the latter would allow us
to write Python "extensions" that could be compiled to C and run really
efficiently...which is a very interesting part of the problem for those
of us interested in Python for its own sake. I think that requiring that
the subset be rich enough that everything else can be defined (not just
implemented, but defined) in terms of it sets a very high bar. Python
wasn't designed from first principles so discovering them after the fact
will be tricky.

Let me suggest what I would use as my "benchmark" if I were going to
take on a project like this in my university days. Make a Python
subset/compiler which uses type declarations. Demonstrate that modules
that previously could only be written in C can now be written in Python
because the speed difference has narrowed.

> I think you could get away with defining a subset that only permits 
> single-inheritance, doesn't allow the use of special methods like
> __getattr__ and __setattr__, doesn't allow addition or removal of
> methods after class initialization, doesn't allow classes or instances
> to change their base classes, and only permits class declarations
> at toplevel. 

He could make a subset that does not do inheritance at all without
losing any functionality from C. If it makes his life easier, he could
even pretend that classes don't exist in the same way that C extensions
do. I wouldn't mind coding my inner loops in a non-OO subset. In fact,
there would be rejoicing in the streets if we could avoid C's headaches
for even 30% of what we currently do in C for speed reasons.

Anyhow, if we went back to the "Py core" approach, I'm not clear how you
would decide what to discard. You can't discard anything with
first-class syntax because Python doesn't have an extensible syntax. 
The Lisp guys get away with it through macros and function calls. We
don't have that option.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/~perlis-alan/quotes.html