Alternatives to multiple inheritance
I’m writing a scripting language using RPython. I have a base class for all my objects. Now, I have an exception object. The exception object needs to derive from my base class in order for me to use polymorphism inside the interpreter. However, it also needs to derive from the Exception class to be throwable. My code looked kind of like this: class BaseObject(object): pass class MyException(BaseObject, Exception): ... However, upon trying to compile the code, I got this error: [translation:ERROR] AssertionError: multiple inheritance only supported with _mixin_: <class 'bolt.objects.BoltException'> [translation:ERROR] Processing block: [translation:ERROR] block@122 is a <class 'rpython.flowspace.flowcontext.SpamBlock'> [translation:ERROR] in (bolt.main:10)parse_and_run [translation:ERROR] containing the following operations: [translation:ERROR] v0 = simple_call((type interpreter)) [translation:ERROR] --end-- bolt.objects.BoltException is my exception class. If I remove the Exception base, I get this: [translation:ERROR] AssertionError [translation:ERROR] Processing block: [translation:ERROR] block@9 is a <class 'rpython.flowspace.flowcontext.SpamBlock'> [translation:ERROR] in (bolt.main:4)run_file [translation:ERROR] containing the following operations: [translation:ERROR] v0 = simple_call((function create_file), p_0, ('r')) [translation:ERROR] v1 = getattr(v0, ('read')) [translation:ERROR] v2 = simple_call(v1) [translation:ERROR] v3 = simple_call((function parse_and_run), v2) [translation:ERROR] v4 = getattr(v0, ('close')) [translation:ERROR] v5 = simple_call(v4) [translation:ERROR] --end-- The only thing about multiple inheritance and RPython I found was this<https://mail.python.org/pipermail//pypy-commit/2011-November/055925.html> . My current idea is to have my base object derive from Exception instead of nothing. I was wondering if there’s a better solution, however. -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
On Thu, Apr 17, 2014, at 15:42, Ryan Gonzalez wrote:
I’m writing a scripting language using RPython. I have a base class for all my objects. Now, I have an exception object. The exception object needs to derive from my base class in order for me to use polymorphism inside the interpreter. However, it also needs to derive from the Exception class to be throwable. My code looked kind of like this:
class BaseObject(object): pass class MyException(BaseObject, Exception): ...
However, upon trying to compile the code, I got this error:
[translation:ERROR] AssertionError: multiple inheritance only supported with _mixin_: <class 'bolt.objects.BoltException'> [translation:ERROR] Processing block: [translation:ERROR] block@122 is a <class 'rpython.flowspace.flowcontext.SpamBlock'> [translation:ERROR] in (bolt.main:10)parse_and_run [translation:ERROR] containing the following operations: [translation:ERROR] v0 = simple_call((type interpreter)) [translation:ERROR] --end--
bolt.objects.BoltException is my exception class. If I remove the Exception base, I get this:
[translation:ERROR] AssertionError [translation:ERROR] Processing block: [translation:ERROR] block@9 is a <class 'rpython.flowspace.flowcontext.SpamBlock'> [translation:ERROR] in (bolt.main:4)run_file [translation:ERROR] containing the following operations: [translation:ERROR] v0 = simple_call((function create_file), p_0, ('r')) [translation:ERROR] v1 = getattr(v0, ('read')) [translation:ERROR] v2 = simple_call(v1) [translation:ERROR] v3 = simple_call((function parse_and_run), v2) [translation:ERROR] v4 = getattr(v0, ('close')) [translation:ERROR] v5 = simple_call(v4) [translation:ERROR] --end--
The only thing about multiple inheritance and RPython I found was this<https://mail.python.org/pipermail//pypy-commit/2011-November/055925.html> .
My current idea is to have my base object derive from Exception instead of nothing. I was wondering if there’s a better solution, however.
In this case, you may want to do what the PyPy Python interpreter does. There is one interpreter level exception for app-level exceptions called OperationError. OperationError wraps the app-level exception object inside of it.
Hi Ryan, On 18 April 2014 01:13, Benjamin Peterson <benjamin@python.org> wrote:
On Thu, Apr 17, 2014, at 15:42, Ryan Gonzalez wrote:
The exception object needs to derive from my base class in order for me to use polymorphism inside the interpreter. However, it also needs to derive from the Exception class to be throwable.
In this case, you may want to do what the PyPy Python interpreter does. There is one interpreter level exception for app-level exceptions called OperationError. OperationError wraps the app-level exception object inside of it.
In other words, the easiest is to have a class OpError(Exception) that wraps your real exception object; then raise and catch "OpError(your_object)" and don't do anything else with the OpError class. RPython is not C++ is that you can't throw and catch random things (like integers...). But then it is not C++ in that it has better malloc-removal support :-) A bientôt, Armin.
That makes sense! Thanks a lot! On Fri, Apr 18, 2014 at 1:44 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Ryan,
On 18 April 2014 01:13, Benjamin Peterson <benjamin@python.org> wrote:
On Thu, Apr 17, 2014, at 15:42, Ryan Gonzalez wrote:
The exception object needs to derive from my base class in order for me to use polymorphism inside the interpreter. However, it also needs to derive from the Exception class to be throwable.
In this case, you may want to do what the PyPy Python interpreter does. There is one interpreter level exception for app-level exceptions called OperationError. OperationError wraps the app-level exception object inside of it.
In other words, the easiest is to have a class OpError(Exception) that wraps your real exception object; then raise and catch "OpError(your_object)" and don't do anything else with the OpError class.
RPython is not C++ is that you can't throw and catch random things (like integers...). But then it is not C++ in that it has better malloc-removal support :-)
A bientôt,
Armin.
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
participants (3)
-
Armin Rigo -
Benjamin Peterson -
Ryan Gonzalez