Re: [pypy-dev] DLS paper on RPython
[I respond only to you because I don't think Massimo and Davide are interested in such details; I'm also cc-ing pypy-dev] Niko Matsakis wrote:
Probably the simplest way to solve the problem is not to allow arbitrary objects to be thrown in RPython; I quick grep inside objspace/std and interpret didn't show any case in which this feature is used, and in any case it should be very easy to patch. Else, you could special-case the raise/except when using subclasses of Exception, and don't do the wrapping in those cases; of course you would have to be careful when catching all the exceptions, something like this: try: foo() except: bar() needs to be translated to: try { foo() } catch(Exception e) { // this is __builtin__.Exception bar() } catch(ExceptionWrapper e) { bar() } or something similar. I think we should really try to avoid ExceptionWrapper beacuse it's both ugly and probably veeery slow. ciao Anto
I guess the question is whether people consider the ability to throw arbitrary objects (rather than only those whose type is a subtype of Exception) a feature or a bug. I'm on the fence myself: it makes translating to the jvm and clr easier if we prohibit arbitrary objects, and it seems like a marginal use-case, but on the other hand, well, Python can do it, so why not? If anyone wanted to give me a few pointers as to what has to be changed to force exceptions to be subtypes of Exception, I'd be excited to try hacking it, just so I can learn more about that part of PyPy. On the other hand, I think that a hybrid wrapping strategy could actually work reasonably well and avoid wrapping in the 99% of cases where Exception sub-types are thrown and caught. Therefore, I'd say the real question is how people on the list think that RPython "ought" to behave. Niko
Niko Matsakis wrote:
the idea is that only subclasses of Exception/BaseException can be thrown in RPython, we have no code to enforce that right now OTOH if you find places in our RPython code that don't do that those are bugs to fix.
Okay, I guess the right thing to do then is to insert a CHECKCAST when the static type of a thrown exception is not a sub-type of Exception. "Correct" RPython should work, and the rest will throw a ClassCastException. If the annotator/rtyper were later changed to provide a static type better than Object, then the casts won't be generated. That's what I've done for now. It fixes the broken test, at least. :) Niko
"Niko Matsakis" <niko@alum.mit.edu> wrote in message news:FF531020-FE60-47B2-A30F-CB13D6E696F0@alum.mit.edu... |I guess the question is whether people consider the ability to throw | arbitrary objects (rather than only those whose type is a subtype of | Exception) a feature or a bug. | | I'm on the fence myself: it makes translating to the jvm and clr | easier if we prohibit arbitrary objects, and it seems like a marginal | use-case, but on the other hand, well, Python can do it, so why not? 'Python can do it'??? In 2.4, only throw (old-style) classes or instances thereof or (deprecated) strings. In 2.5, I believe base exception was made new style. In 3.0, I expect subtype thereof will be enforced. tjr
I guess the question is whether people consider the ability to throw arbitrary objects (rather than only those whose type is a subtype of Exception) a feature or a bug. I'm on the fence myself: it makes translating to the jvm and clr easier if we prohibit arbitrary objects, and it seems like a marginal use-case, but on the other hand, well, Python can do it, so why not? If anyone wanted to give me a few pointers as to what has to be changed to force exceptions to be subtypes of Exception, I'd be excited to try hacking it, just so I can learn more about that part of PyPy. On the other hand, I think that a hybrid wrapping strategy could actually work reasonably well and avoid wrapping in the 99% of cases where Exception sub-types are thrown and caught. Therefore, I'd say the real question is how people on the list think that RPython "ought" to behave. Niko
Niko Matsakis wrote:
the idea is that only subclasses of Exception/BaseException can be thrown in RPython, we have no code to enforce that right now OTOH if you find places in our RPython code that don't do that those are bugs to fix.
Okay, I guess the right thing to do then is to insert a CHECKCAST when the static type of a thrown exception is not a sub-type of Exception. "Correct" RPython should work, and the rest will throw a ClassCastException. If the annotator/rtyper were later changed to provide a static type better than Object, then the casts won't be generated. That's what I've done for now. It fixes the broken test, at least. :) Niko
"Niko Matsakis" <niko@alum.mit.edu> wrote in message news:FF531020-FE60-47B2-A30F-CB13D6E696F0@alum.mit.edu... |I guess the question is whether people consider the ability to throw | arbitrary objects (rather than only those whose type is a subtype of | Exception) a feature or a bug. | | I'm on the fence myself: it makes translating to the jvm and clr | easier if we prohibit arbitrary objects, and it seems like a marginal | use-case, but on the other hand, well, Python can do it, so why not? 'Python can do it'??? In 2.4, only throw (old-style) classes or instances thereof or (deprecated) strings. In 2.5, I believe base exception was made new style. In 3.0, I expect subtype thereof will be enforced. tjr
participants (4)
-
Antonio Cuni -
Niko Matsakis -
Samuele Pedroni -
Terry Reedy