I think this was a fascinating discussion, a high point for edu-sig in
many ways, and thank the participants (not saying it's over, just
some will move on at this point, I have a feeling).
So I finished my 5th of 5 sessions in SA: 8629, feel free to give it
a browse if you wanna see how we do it in Portland.
All five sessions in forward-time order:
{
1 : http://controlroom.blogspot.com/2008/04/sa-classnotes-2008419.html,
2 : http://controlroom.blogspot.com/2008/04/sa-classnotes-2008426.html,
3 : http://controlroom.blogspot.com/2008/05/sa-classnotes-200853.html,
4 : http://controlroom.blogspot.com/2008/05/sa-classnotes-2008510.html,
5 : http://controlroom.blogspot.com/2008/05/sa-classnotes-2008517.html
}
Kirby
Addendum:
As an implementation detail, you might have to copy a lot more bytes
when you go x = y, if the object you're controlling at runtime is a
long way away, but you want to cache more locally for some reason.
You might end up with a synchronization scheme, similar to ACID for
databases, such that you preserve the "shared reference" experience --
but with a lot of work behind the scenes to effectively preserve that
"illusion" (not really an illusion then?).
I offer this simply to underscore the point that Michael Goldwasser
was making (I learned a lot from his posts), about there being a big
difference between modeling *semantics* and modeling *implementation*.
In my view, C was / is all about implementation (wall of memory
bricks), is about being "close to the metal". The model and
implementation are very deliberately coincident.
However, as a hallmark of being "high level," Python expects us to
forget about the metal and develop alternative "best fit" concepts.
A semantic model *need not* point back to the underlying
implementation, although when you start saying stuff like 'heap',
'string' and 'hash table' (aka dictionary) then you're starting to
enter C territory (a whole family of concepts, owes much to K&R).
There's a difference with emphasis on newcomers to programming. For
example, are these people headed into electrical engineering and
needing to understand computer guts in great detail, or are they
biomedical researchers who only care about Python because it helps
them understand their molecules.
The very same CS department might customize entirely different courses
based on these differing career goals.
These latter programmers may never read K&R nor even be clear there's
a C family of languages. That doesn't mean they're necessarily more
clueless about Python's semantic model however, or are "mere
beginners" with Python.
On the contrary, they understand as well as anyone that adding to a
namespace need not involve the unnecessary replication of the
underlying objects.
Anyway, go ahead and import the copy module if you really know that's
a good solution (at least you'll think twice about it).
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
