[Edu-sig] Interesting "gotcha"
carl at free.org.nz
Wed Mar 30 01:09:24 CEST 2011
My experience of confusing boolean expressions was the code:
>>> 1 == 2 in [2, False]
which, when parenthesised the two possible ways
>>> (1 == 2) in [2, False]
>>> 1 == (2 in [2, False])
results in sensible values (although the second one's sensibility is
I couldn't figure it out quickly either. In fact, I ended up decompiling to
byte code to figure out what was going on.
As far as other 'gotcha's in addition to the ones already mentioned:
Calling a file the same name as a module in the standard library. Import
<name> will get the local file, not the stdlib one, which is confusing if
you wanted the stdlib one.
I've noticed that students will somtimes put import statements inside a
function - right before they need to use whatever they imported:
On 29 March 2011 18:06, Michael H. Goldwasser <goldwamh at slu.edu> wrote:
> To start a new thread, I'm always trying to keep a list of some common
> "gotchas" that beginning students run across when using Python, or
> things that teachers should keep in mind when teaching with the
> language. I have in mind commands that do not generate runtime errors,
> but are likely to lead to logical errors that are not apparent to
> students, and most of these are legal due to the very flexible nature
> of the Python language. Some classicss are
> data.sort # no-op
> data = data.sort() # bye-bye data
> result = result.upper # probably not what you expect
> if answer.isupper: # always true ("but I entered a lowercase
> This semester, I ran across a new one that took me quite some time to
> figure out what was happening. This started with a habit that too
> many students have of wanting to compare boolean values to True/False
> literals, rather than just using the boolean as a condition. That is,
> students seem drawn to the syntax
> if answer.isupper() == True:
> rather than the preferred
> if answer.isupper():
> These complaints are more of style than substance, as the two
> versions are logically equivalent. But then a student came to me
> with code that wasn't behaving. The syntax they used was something
> akin to
> if x > y == True:
> however the condition was not being triggered, even when we verified
> that x was indeed greater than y. You can try this out with explicit
> values as follows.
> >>> if 5 > 4 == True:
> ... print "Good"
> You will find that the body is not executed. More directly, you can
> look at the conditional value directly as
> >>> 5 > 4
> >>> 5 > 4 == True
> This baffled me for an hour before finally seeing what was happening.
> I'll leave this as a puzzle for readers (many of whom I'm sure will be
> quicker than I was to see the solution). For those who give up, I
> offer the following link as a spoiler.
> With regard,
> | Michael H. Goldwasser, Ph.D.
> | Associate Professor
> | Director of Computer Science
> | Dept. Mathematics and Computer Science
> | Saint Louis University
> | 220 North Grand Blvd.
> | St. Louis, MO 63103-2007
> | Office: Ritter Hall 108
> | Email: goldwamh at slu.edu
> | URL: http://cs.slu.edu/~goldwasser
> | Phone: (314) 977-7039
> | Fax: (314) 977-1452
> Edu-sig mailing list
> Edu-sig at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Edu-sig