On Sat, Jul 3, 2010 at 2:51 AM, Craig Citro <craigci...@gmail.com> wrote:
>> 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's probably a slippery slope once you start deciding which bits
> of semantics raise CompileErrors and which don't.
>
> However, in this particular case, here's a question: *why* would
> someone write "return 1 + '1'"? Did they do it *knowing* what would
> happen, or because they just didn't realize it was just an error?
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"
If an end user is doing it rather than an implementation's own test
suite... well, I have no idea why anyone else would want to do that :)
> My real motive, though, is that I'd like to have more freedom for
> Python implementations, *especially* things that let you make more
> decisions at compile-time. (This is no doubt influenced by the fact
> that I've spent a lot of time thinking about Cython lately.) In this
> case, I see it as a win-win -- it gives more freedom to the folks
> writing the implementation, and (personally) I find it more pleasing
> as a user. Again, I don't think this *particular* case allows us to do
> something awesome behind the scenes with Cython -- but the community
> starting to consider changes of this ilk *would* be a big win, I
> think.
It's definitely something of a grey area. The existing test suite
would likely fail if "obviously insane" operations between literals
started throwing SyntaxError, but it would be possible to classify
some of those tests as implementation specific. However, an
implementation that did that would need to completely fork any
affected parts of the test suite, since the implementation specific
test decorators won't help protect against failures to compile the
code.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
