On Fri, Jul 2, 2010 at 10:35 PM, Steven D'Aprano st...@pearwood.info wrote:
On Sat, 3 Jul 2010 11:39:07 am Greg Ewing wrote:
Stefan Behnel wrote:
So, would it still be Python if it folded
1 + 1
into
raise TypeError()
at compile time?
It would have to be
raise
Steven D'Aprano, 03.07.2010 06:35:
On Sat, 3 Jul 2010 11:39:07 am Greg Ewing wrote:
Stefan Behnel wrote:
So, would it still be Python if it folded
1 + 1
into
raise TypeError()
at compile time?
It would have to be
raise TypeError(Exactly the message that would have been
Glyph Lefkowitz, 02.07.2010 06:43:
On Jul 2, 2010, at 12:28 AM, Steven D'Aprano wrote:
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an
On Fri, Jul 2, 2010 at 12:31 AM, Stefan Behnel stefan...@behnel.de wrote:
Glyph Lefkowitz, 02.07.2010 06:43:
On Jul 2, 2010, at 12:28 AM, Steven D'Aprano wrote:
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that
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 1158293
6 IMPORT_STAR
7 SETUP_EXCEPT25968 (to 25978)
Am 02.07.2010 08:55, schrieb Craig Citro:
This question has an easy answer - can you possibly tell the difference?
Ok, I'm obviously being silly here, but sure you can:
The dis module is deliberately (*) not part of the Python language and
standard library; it's an implementation detail (as
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro craigci...@gmail.com wrote:
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_EXCEPT 25968 (to 25978)
On Fri, Jul 2, 2010 at 8:22 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro craigci...@gmail.com wrote:
dis.dis(raise TypeError())
0 114 26977
3 115 8293
6 IMPORT_STAR
7 SETUP_EXCEPT 25968
On Fri, Jul 2, 2010 at 1:20 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 02.07.2010 08:55, schrieb Craig Citro:
This question has an easy answer - can you possibly tell the difference?
Ok, I'm obviously being silly here, but sure you can:
The dis module is deliberately (*) not part of
On Fri, 2 Jul 2010 04:55:10 pm Craig Citro wrote:
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 1158293
6
On Fri, Jul 2, 2010 at 12:25 PM, Steven D'Aprano st...@pearwood.info wrote:
Craig, what are you using to get that? When I try it in Python 3.1, I
get:
TypeError: don't know how to disassemble str objects
How do you get that result?
As I just discovered (see above), dis.dis is happy to
On Fri, Jul 2, 2010 at 4:55 PM, Craig Citro craigci...@gmail.com wrote:
Honestly, though, I'd come down on the side of letting the compiler
raise an error -- while I understand that it means you have
*different* behavior, I think it's *preferable* behavior.
But you would be taking a module
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 actually
On Fri, Jul 2, 2010 at 3:44 PM, Craig Citro craigci...@gmail.com wrote:
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
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
Am 02.07.2010 18:51, schrieb Craig Citro:
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
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
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 I bet we
On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro craigci...@gmail.com wrote:
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
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
On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro craigci...@gmail.com wrote:
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
2010/7/2 Guido van Rossum gu...@python.org
On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro craigci...@gmail.com
wrote:
1/0 is much faster to type than raise SomeError and serves the same
purpose sometimes for debugging
On 7/2/2010 12:43 AM, Glyph Lefkowitz wrote:
def f(): return 1 + 1
instead of compiling something which can't fail to raise an
exception, would that still be a legal Python implementation?
I'd say no. Python has defined semantics in this situation: a
TypeError is raised.
The manuals are
Wow! I didn't expect anywhere near this amount of interest. Thanks to
all who responded. One small comment follows:
On Sat, 3 Jul 2010 03:44:05 am Guido van Rossum wrote:
On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan ncogh...@gmail.com
wrote:
Given the diverse range of uses Python is put
Stefan Behnel wrote:
So, would it still be Python if it folded
1 + 1
into
raise TypeError()
at compile time?
It would have to be
raise TypeError(Exactly the message that would have been produced at run
time)
That might be acceptable, but then you have to ask, is it really
Craig Citro wrote:
Ok, I'm obviously being silly here, but sure you can:
dis.dis(raise TypeError())
If producing different bytecode were considered a reason
against performing an optimisation, then no code optimisations
would be permissible at all!
--
Greg
Steven D'Aprano wrote:
if the keyhole optimizer raised SyntaxError (or
some other exception) on seeing this:
def f():
return 1 + 1
That might break code that was deliberately trying to raise
an exception. Sometimes you see things like
try:
1/0
except Exception, e:
...
On Sat, 3 Jul 2010 11:39:07 am Greg Ewing wrote:
Stefan Behnel wrote:
So, would it still be Python if it folded
1 + 1
into
raise TypeError()
at compile time?
It would have to be
raise TypeError(Exactly the message that would have been
produced at run time)
Craig Citro wrote:
However, in this particular case, here's a question: *why* would
someone write return 1 + '1'?
They might not intend to execute the code at all -- e.g.
they may want to pass the compiled code to dis() to find
out what bytecode gets generated. Having it refuse to
compile
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an implementation rejected them at compile time, would it
still be Python? E.g. if the keyhole
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an implementation rejected them at compile time, would it
still be Python? E.g. if the keyhole optimizer raised SyntaxError (or
some other exception) on seeing this:
def f():
return 1 + 1
instead
On Jul 2, 2010, at 12:28 AM, Steven D'Aprano wrote:
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an implementation rejected them at
32 matches
Mail list logo
