[Edu-sig] teaching Python

[David MacQuigg]

Mark Engelberg wrote:
> On Fri, Apr 23, 2010 at 2:41 PM, David MacQuigg wrote:
>
>> Would you rather have Python do something different?
>
> My own preference is that I would like 5*[[]] to be syntactic sugar for:
> [ [ ] for i in range(5)]

Then what about 5*[x], 5*[[x]], 5*[[3,x]], ... where x itself can be a 
list, a list of lists, or any complex object?  How deep would you go in 
creating distinct objects?  Would you want similar behavior for 
dictionaries, or is this just something special for lists?  What about 
other operators?  Is [x] + [x] no longer equivalent to 2*[x]?  We need a 
clear, concise rule for when to generate distinct objects, and when to 
keep the current, and more efficient behavior - multiple references to 
the same object.

> I find this to be more intuitive, and I believe this is what most
> people incorrectly assume the syntax expands to.
>   

The important thing is not that our initial guess is right in every odd 
case, but that the syntax be simple and consistent, so we get it right 
if we think about it.  My initial guess was wrong, but that is OK with 
me, because 1) I could have figured it out if I had taken the time, and 
2) I usually don't take the time to figure these things out. I just pop 
an example in the interpreter, and see if I get what I want.

The seemingly bizarre behavior of a = 5*[[]] is not so bizarre if you 
really understand the relationship between variables and objects in 
Python.  It's simple, but it's different than other languages.  Our 
students start with C, so when I explain Python, I really emphasize the 
difference.  
http://ece.arizona.edu/~edatools/ece175/Lecture/python-variables.htm

> If that's the way it worked, literals would always create fresh copies
> each time through the loop, but if you still want shared behavior, you
> could do it explicitly with something like:
> x = []
> a = 5*x
>   

That changes the meaning of * for list objects from its current and very 
useful semantics of "extend this list", and five times empty is still empty.

> Anyway, every language has its shares of gotchas.

Agreed.  I think of language design as laying a carpet in an odd-shaped 
room (the real world of problems we need to solve).  A good design like 
Python will be very smooth in the middle, and the wrinkles will be at 
the edges.  I've never needed to construct a list of lists, identical in 
value, but distinct objects in memory, so this is an edge-case for me.

Bill's example of accidental scoping is a much more troublesome gotcha.  
Even if you are not pushing the edges, a simple mis-spelling coupled 
with Python's complex implicit scoping rules, can result in an error not 
detected by the interpreter or even by pychecker.

If I were designing a language, external variables would always be 
explicitly declared, and the rule would be simple.  An external variable 
refers to the nearest enclosing scope in which that variable is assigned 
a value.  No difference if the enclosing scope is a class or another 
function or the module itself.  No need for a 'global' keyword that 
actually means "module level", not truly global.

-- Dave