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
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
