Explanation of list reference

Rustom Mody rustompmody at gmail.com
Fri Feb 14 23:24:20 EST 2014


On Saturday, February 15, 2014 9:03:36 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Feb 15, 2014 at 2:14 PM, Rustom Mody wrote:
> > On Saturday, February 15, 2014 8:12:14 AM UTC+5:30, Chris Angelico wrote:
> >> Well, for a start, I'd use Python 3, so there's no need to explain why
> >> some numbers have an L after them :)
> > Nice point!
> > And only sharpens what I am saying -- python 3 is probably more confusing than
> > 2 wrt object identity

> How so? Py3 eliminates an unnecessary difference:

> >>> 1L == 1
> True
> >>> 1L is 1
> False

> In Py3, this can't happen, because there simply is no distinction.

> (That said, the Py3 unification does mean that small integers pay the
> performance cost of long integers. I've mentioned before that it may
> be worth having an "under the covers" optimization whereby small
> integers are stored in a machine word - but this should be utterly
> invisible to the user. As far as the programmer's concerned, an int is
> an int is an int.)

> >> When it's utterly impossible for it to matter in any way, Python is
> >> allowed to reuse objects.
> >> I think that's simple enough to explain. There's nothing you can do to
> >> distinguish one 6 from another, so Python's allowed to have them the
> >> same.
> > Simple??
> >>>> x=1234
> >>>> y=1234
> >>>> x is y
> > False
> >>>> 1234 is 1234
> > True
> >>>> x=123
> >>>> y=123
> >>>> x is y
> > True

> In all three cases, Python is allowed to use separate objects. Nothing
> forces them to be shared. But in all three cases, there's no way you
> could distinguish one from another, so Python's allowed to reuse the
> same object.

> > "utterly impossible to matter"...
> > "nothing you can do to distinguish one 6 from another"
> > All depend on doing one of these 3 for dealing with object identity
> > 1. Circular definition
> > 2. Delve into implementation
> > 3. Wildly wave the hands

> How do you distinguish between any other identical things? Once you've
> decided that they're equal, somehow you need to separate identity from
> value.

Implicit circularity problem continues... See below

> I could have three six-sided dice, all made from the same
> mould, and yet each one is a separate object. If I hold all three in
> my hand and toss them onto the table, can I recognize which one is
> which? No, they're identical. Are they distinct objects? Yes.

In the case of physical objects like dice there is a fairly
unquestionable framing that makes identity straightforward --
4-dimensional space-time coordiantes. If the space-time coordinates of
2 objects are all equal then the objects are identical, else not.

Now we analogize the space-time identity of physical objects to
computer identity of computer objects (so-called) and all sorts of
problems ensue.

To start with we say two objects are identical if they have the same
memory address.
Then what happens to the same memory address on different computers?
If you say nothing on two different computers are identical then how do you
define the correctness of a serialization protocol?

And is 'different computer' even well-defined? Think of clusters, COWs NOWs,
and other beasties ending in the cloud...

IOW when we analogize 4-dim infinite space-time into the confines of
'a computer' weve bought bigger problems than we disposed off, because

- for space-time it is unreasonable to imagine a larger frame into which that is
embedded

- for computers that larger frame is a key part -- starting with the fact
that you and I are having a conversation right now

tl;dr Analogizing physical objects to computer 'objects' is a mistake



More information about the Python-list mailing list