I am a big fan of discovery learning, and thus down on anything that
interferes with discovery. I practice what I call defensive
documentation on such problems, as do some others. See for example,
The C Puzzle Book, and my Sugar Labs page
We will need comprehensive, user-friendly documentation of gotchas in
Python and Smalltalk for the Sugar project, for the benefit of
teachers and students alike.
On Tue, Mar 29, 2011 at 19:09, Carl Cerecke <[hidden email]> wrote:
> 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:
> def area(r):
> import math
> return math.pi*r*r
> On 29 March 2011 18:06, Michael H. Goldwasser <[hidden email]> 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: [hidden email]
>> | URL: http://cs.slu.edu/~goldwasser
>> | Phone: (314) 977-7039
>> | Fax: (314) 977-1452
>> Edu-sig mailing list
>> [hidden email]
> Edu-sig mailing list
> [hidden email]
Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
Edu-sig mailing list
|Free forum by Nabble||Edit this page|