The Undiscoverable (was Re: Interesting "gotcha")

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

The Undiscoverable (was Re: Interesting "gotcha")

Mokurai
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

http://wiki.sugarlabs.org/go/The_Undiscoverable

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]
> False
>
> which, when parenthesised the two possible ways
>>>> (1 == 2) in [2, False]
> True
>>>> 1 == (2 in [2, False])
> True
> results in sensible values (although the second one's sensibility is
> debatable)
>
> 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
>
> Cheers,
> Carl.
>
> 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
>> answer")
>>
>>
>> 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
>> True
>> >>> 5 > 4 == True
>> False
>>
>> 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.
>> http://docs.python.org/reference/expressions.html#comparisons
>>
>> With regard,
>> Michael
>>
>> +-----------------------------------------------
>> | 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]
>> http://mail.python.org/mailman/listinfo/edu-sig
>
>
> _______________________________________________
> Edu-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/edu-sig
>
>



--
Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://www.earthtreasury.org/
_______________________________________________
Edu-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/edu-sig