> >>> ( eval( 'a.'+[].__methods__[-2] )() or a )
> >>> import sys
> >>> eval( eval( 'dir()[-1]', sys.__dict__ ), sys.__dict__ )
Oh, bletch! Those are disgusting, Steve. I can't compete at this level
of perversity, but I do encourage you to keep up the delightfully
revolting work <smile>.
> >>> 1 or 2
> Parsing error: file <stdin>, line 1:
> 1 or 2
> ^
> SyntaxError: invalid syntax
> >>> ( 1 or 2 )
> 1
>
> Is this just an residue of the days when the parser had
> to distinguish between boolean and binding "=", or does
> it fulfill some other syntactical need ?
These behaviors still follow from the formal syntax in the reference
manual, but I'm not sure they _need_ to anymore (I too recall them
stemming from the need to disambiguate a=b=c back in the days when "="
was the both the equality and the assignment operator).
I often get burned by this variation too:
for i in 1,2,3:
is legit, but
if i in 1,2,3:
is a syntax error (needs to be
if i in (1,2,3):
or a moral equivalent instead).
And the following is a very subtle oops-you-really-wanted-a-tuple there
mistake (subtle because it's not a syntax error):
try:
some_code()
except ZeroDivisionError, NameError:
pass
I.e., if some_code() does raise ZeroDivisionError, the name NameError
gets bound to 'integer division or modulo' (the "detail" of the
ZeroDivisionError), and so any subsequent attempt to catch NameError will
fail.
It took an awful long time to figure out what went wrong when (something
similar to) this bit me in a real program. But I don't complain, because
it broke me of the bad habit of relying on catching exceptions <0.9 grin>.
thank-god-i-still-smoke-ly y'rs - tim, grateful for one vice
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp