[Edu-sig] How does Python do Pointers?

[kirby urner]

Just to add a few words, I think a big dog, like an English Mastiff,
tugging really hard on a leash, would be a good place to start, in
some cartoon YouTube about Python.

When I get to some dog washing storefront, I hand another leash to the
dog washer, same dog at the end, washer goes inside, has control of
the dog object, does local scope thing with soap. The dog at the other
end of my leash (was there the whole time) gets a good cleanup (thanks
to this function).

Maybe better than a post-it is a remote controller like for robot, or
console game system?  Lots of little buttons, some strangely shaped.

Your having a name (handle, token) means you can do stuff like
dog.attribute, dog( ) -- called calling, triggers __call__ -- dog[ ]
(__getitem__) other syntax games (maybe use operators as in dogA +
dogB).

The point is your "post-it" (remote) has all these triggering
abilities, makes you the puppet master of the (maybe faraway) object.

So it's a combination of those images:  like a leash, or a rope, a
connection, but also a set of controls, ways to send messages, read
state, trigger methods (however we want to talk about it -- standard
OO ways of doing so).

When we get to a function, we hand over a set of controls (a remote,
an api), which get destroyed when they go out of scope, but in the
meantime give the local scope some control or at least contact with
the underlying controlees (the objects).

These objects usually have no way of knowing the identities of their
potentially many handlers -- you could code that in some higher level
MVC, but Python out of the box keeps objects in the dark about such
matters.

Kirby
4D

Sorry for typos below:

On Tue, May 6, 2008 at 3:43 PM, kirby urner <kirby.urner at gmail.com> wrote:
> Although I like the post-its analogy, good advertising for 3M, there's
>  an implied thesis about proximity (post-its "stick to" something)
>  whereas I'd like students to thing of objects as potentially very
>  heavy and far removed, connected more by wire or rope.
>
>  This matches very early conversations about edu-sig about Python's
>  bias against copying, i.e. you need to import from a separate module,
>  and even then, deepcopy is something special, considered usually
>  unneeded, i.e. Python the design, like any design, encourages and
>  discourages ways of thinking, and Guido is pretty clear about what
>  he's trying to cut down on (copying).
>
>  Because once your names really do point to objects, potentially
>  associated with huge amounts of data (as objects may be), then you
>  really *don't* want some x = y assignment to involve truly copying
>  anything, as that implies potentially major consequences in memory
>  sometimes.
>
>  So I'd say Python's emphasis on names sharing an object, is consistent
>  with Python's strong bias against copying.
>
>  I like the point made earlier that parameter passing at the function
>  gateway is all about assignment, and assignment is all about cloning a
>  pointer or reference, for use within the local scope, and these names
>  are by definition something tiny, whereas the objects themselves --
>  who knows how big these might be.
>
>  Kirby