[Edu-sig] Sticky-note Analogy

[kirby urner]

On Thu, May 8, 2008 at 10:48 AM, David MacQuigg
<macquigg at ece.arizona.edu> wrote:

> 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.

Yes, x = y = z = 0 is a way of passing through an assignment, from a
single legal right sider (in this case an object designated with a
literal) to three legal left siders (variable names, assignable
tokens, invented for the namespace and not hardwired in Python to
immutables like True or False or 0 are hardwired).

Left siders may be Chinese ideograms or Hebrew strings since Python
3.0, likewise function and class names, as used in their definitions
with the keywords def and class respectively (keywords stay in their
Latin-1 forms, as does the __rib__ cage etc.).

A question is whether existing or future PEPs will suggest opening the
__rib__ cage to non-Latin-1 characters, such as for operator
overloading i.e. new operators in Klingon or whatever.  As of now, the
list of special names is closed to the programmer.

x = y wouldn't make any sense if y weren't already a name of some
object, which is why def f ( x = y ): is only legal Python if there's
a y already defined in the namespace.  def f (x = 0): always makes
sense, because 0 is in every Pythonic namespace, as is '0'.

>>> del 8
SyntaxError: can't delete literal
>>> del '8'
SyntaxError: can't delete literal

I've suggested seeing 8 as a name ("seeing as" as in "temporary
gestalt switch"), even though it's a literal, just so we briefly
understand it's also a token, like eight, such that 8 .__add__(5)
means essentially the same thing as eight = 8; eight.__add__(5),
except we add to the namespace in the latter example (by contributing
the name eight).

In terms of the postit analogy, I would agree that we don't stick
post-its on post-its (we just don't), because to assign is to
pass-by-value an object reference or pointer (something more than a
memory address, because it provides an API to the referenced object),
and top-level names aren't themselves something we point to.  We *use*
names, we don't *reference* them.  Names conspire amongst themselves
to only point off stage to objects.  A namespace as a whole (think of
a module) is a memory management scheme (it works with stuff in
memory, on the heap), with the various objects managed in the guts of
the Python interpreter (very agile).

I think it's helpful in some cases to say "all objects are essentially
anonymous including the one designated by 8."  This is another way of
saying that average workaday objects don't really care what they're
called.  Objects are blissfully ignorant of their own names.  However,
with the gc module and such, it's possible for the Python interpreter
to introspect, i.e. there are ways to get at this information, outside
of interrogating the objects.

Kirby