On Fri, Jul 2, 2010 at 10:35 PM, Steven D'Aprano 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 b
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
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 wo
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
> p
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:
...
Usua
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
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
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
wrote:
> > Given the diverse range of uses Python is put to, moving things
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 ar
2010/7/2 Guido van Rossum
> On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan wrote:
> > On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro
> 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
> >>
On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan wrote:
> On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro 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 :)
>>
> 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
On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro 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 extra c
> "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
On Sat, Jul 3, 2010 at 2:51 AM, Craig Citro 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
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
> 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'
On Fri, Jul 2, 2010 at 3:44 PM, Craig Citro 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 different
> bytecod
> 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
On Fri, Jul 2, 2010 at 4:55 PM, Craig Citro 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 that will compile and
On Fri, Jul 2, 2010 at 12:25 PM, Steven D'Aprano 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 interpret byte
stri
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 <115>8293
>
On Fri, Jul 2, 2010 at 1:20 AM, "Martin v. Löwis" 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 the P
On Fri, Jul 2, 2010 at 8:22 AM, Mark Dickinson wrote:
> On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro wrote:
>>
> 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 7:55 AM, Craig Citro 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)
> 10
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
> 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
On Fri, Jul 2, 2010 at 12:31 AM, Stefan Behnel 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 m
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 imp
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
> 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"
>
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
32 matches
Mail list logo
