> To test that adding a string to an integer raises TypeError at
> runtime. That is, something along the lines of:
>
> with self.assertRaises(TypeError):
> 1 + "1"
>
Well, this would just mean the test suite would have to change -- that
test would become something like
with self.assertRaises
> "1/0" is much faster to type than "raise SomeError" and serves the same
> purpose sometimes for debugging purposes. Let's not forget that not
> all code is written for eternity :)
>
Doesn't "raise" do the same thing for just two extra characters?
I agree that not all code lives forever -- but
> But you would be taking a module that will compile and making it uncompilable.
>
You're absolutely right, and since I definitely *don't* think that the
program "raise TypeError" should cause a CompileError, you could say
it's safer to have a simple rule like "vaild syntax => will compile"
-- it'
> Whoa. That's very peculiar looking bytecode. Is dis.dis behaving as
> it should here?
> BTW, I think you want 'raise TypeError', not 'raise TypeError()'.
>
Yep, that's embarrassing. I was being lazy: I was expecting different
bytecodes, and I got it ... so I apparently didn't bother to actuall
> This question has an easy answer - can you possibly tell the difference?
>
Ok, I'm obviously being silly here, but sure you can:
>>> dis.dis("raise TypeError()")
0 <114> 26977
3 <115>8293
6 IMPORT_STAR
7 SETUP_EXCEPT25968 (to 259
> There has been some contentious debate about this in the past, where a
> Cython developer(s?) insisted Cython be listed among the "Python
> implementations" somewhere, on a par with IronPython, Jython and PyPy.
> This does not seem the right place to list Cython to me. (Much though
> I admire Cyt
> I hate to remind you but Cython is *not* python. It does not even plan
> to support all of the parts which are considered python semantics
> (like tracebacks and frames).
>
It's true -- we basically compile to C + the Python/C API, depending
on CPython being around for runtime support, and I don
>> for a college project, I proposed to create a compiler for python. I've
>> read something about it and maybe I saw that made a bad choice. I hear
>> everyone's opinion respond.
>>
I don't think everyone thinks this is a bad idea -- for instance,
those of us working on Cython [1], which is itsel
> Done. The diff is at
> http://codereview.appspot.com/186247/diff2/5014:8003/7002. I listed
> Cython, Shedskin and a bunch of other alternatives to pure CPython.
> Some of that information is based on conversations I've had with the
> respective developers, and I'd appreciate corrections if I'm ou
