At 11:05 AM 5/8/2008 -0400, John Posner wrote:
>> The sticky-note analogy has a flaw. You can't stick one note on top
>> of another. When you say x = y = z, all three variables now point to
>> the object originally pointed to by z. Then when you say y = 8,
>> y now points to an integer object 8, but x doesn't move with y.
>> Python's "sticky notes" have a special glue that sticks only to an
>> object, not to another variable.
>
>IMHO it's not a flaw, but a blessing. Extending the "sticky notes" analogy
>by referring to "special glue" is a very intuitive way to explain the
>language feature you describe above -- assigning then reassigning "y". You
>might not like that language feature, but don't place the blame on the
>analogy!
I too was a little uncomfortable with the wording of this paragraph, but I think it isn't the first sentence that needs revision. We really *don't want* to stick one note on top of another, as the second sentence might imply. Here is a suggested revision:
The sticky-note analogy has a small flaw. If you put one note on top of another, they both move together, and that is not what happens in Python. When you say x = y = 0, both variables now point to an integer object with value 0. Then when you say y = 8, y now points to another object, but x doesn't move with y. Python's "sticky notes" have a special glue that sticks only to
an object, not to another variable.
>> In the classroom we take this a step further and start using a
>> second color post-it note to start laying the framework for the
>> concept of namespaces. If we had been using yellow notes for the
>> names in the caller's context, we start using green notes for names
>> in the local namespace of the function.
>
>Excellent! And you could also use multiple sticky-note colors (or multiple
>shapes -- they exist, too) to introduce the concept of typed variables.
>Switching for a moment to that other thread ("Introducing Python at our
>community college"), I don't think that anyone mentioned using "assert" to
>implement typed variables. Example:
>
> def myfunc(stringparm, listparm, intparm):
> """
> function with typed parameters,
> courtesy of "assert"
> """
> # check parameter types
> assert type(stringparm) is type('abc')
> assert type(listparm) is type(['a', 'b'])
> assert type(intparm) is type(123)
>
> # do the work
> print "All OK"
> return
> # ------------------------------------------
> >>> f.myfunc('a', range(3), 44)
> All OK
>
> >>> f.myfunc(range(3), 44, 'a')
> Traceback (most recent call last):
> File "c:\temp\<string>", line 1, in <module>
> File "c:\temp\f.py", line 6, in myfunc
> assert type(stringparm) is type('abc')
> AssertionError:
The idiom I prefer is
assert isinstance(stringparm, str)
assert isinstance(m, MegaList)
This allows the argument to be a subclass, not just a perfect match. Allowing subclasses is usually what you want.
-- Dave