[pypy-dev] Restricted language

[Armin Rigo]

Hello Christian,

On Tue, Jan 21, 2003 at 03:58:41AM +0100, Christian Tismer wrote:
> Just to make sure I understand what you mean (private mail).
> 
> Having hacked on CPython for a very long time now, I always
> had the impression that CPython never does any distinction
> withing exception, whether they are caused by a script,
> or whether they are caused inside a builtin C object.
> I the runtime decides to throw a memory error, it is the
> same, as if there is a syntax error, or an error in a user
> object.

Yes, I think you are right.  There is some confusion already in the C core
which uses exceptions both for user-program-visible exceptions and internal
handling.  For example, the fact that a generator can signal it is exhausted
by throwing a StopIteration exception (instead of finishing on a "return"):
the StopIteration exception is *internally* used to signal the end of
iterators and a user-level StopIteration should never have been able to
interfere.  Of course, given the way CPython's exceptions are coded, it seemed
natural at the time to add in the definition of the Python language that you
can raise a StopIteration to stop generators...

For memory errors it is still a bit more fuzzy, because it is clearly an
internal error, but there isn't much else that the core can do about it than
turn it into a user-level visible error to cleanly interrupt the user
program...

In Python the RuntimeError exception is reserved for internal errors.  
Ideally it should have been more clearly separated.  But it is tempting to
re-use the existing exception mecanism for RuntimeErrors.  Other interpreters
do that, BTW (e.g. Java).

In Python-in-Python we must internally raise an EPython exception to signal
application-level exceptions, and use the normal exception mecanism for all
other internal error conditions (e.g. use assert's or raise ValueErrors when
internal calls are made with bad values).  In a first phase these would just
crash the interpreter with a traceback that is useful for debugging.  In a
second phase (and only then) we can make the interpreter more robust by
catching *all* unexpected exceptions in the main loop and throwing them into
the application, which would then see them as RuntimeErrors whatever the
original internal exception class had been.

I know this can be quite confusing; it took me some time to figure out this,
but now I am confident that it is the correct point of view.  Again, think
about implementing a Python interpreter in another different language that
also has its own (different) family of exceptions.  If the interpreter
internally raises an unexpected exception, you cannot show it as is in the
Python application because it may have no immediate equivalent.  So you let
the application see a generic RuntimeError exception.  Conversely, if a part
of the interpreter wants to raise, say, a ValueError, there may be no
directly-corresponding exception existing in the interpreter's language; you
have to define a new kind of exception in the interpreter's language, and
throw and catch that exception internally.  This new kind of exception can be
generic ("EPython") and embed information about the Python type and value of
the application-level exception.


A bientôt,

Armin.