Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #67520 > unrolled thread

Reference

Back to article view | Back to comp.lang.python

Contents

  Reference "ast" <nomail@invalid.com> - 2014-03-03 10:42 +0100
    Object identity (was: Reference) Ben Finney <ben+python@benfinney.id.au> - 2014-03-03 21:00 +1100
      Re: Object identity (was: Reference) "ast" <nomail@invalid.com> - 2014-03-03 11:21 +0100
    Re: Reference "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-03 05:09 -0800
    Re: Reference Grant Edwards <invalid@invalid.invalid> - 2014-03-03 14:29 +0000
    Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-03 07:52 -0800
      Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 08:10 +1100
      Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-03 15:24 -0600
      Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 08:31 +1100
      Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-03 21:35 +0000
        Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 00:07 +0200
          Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 09:18 +1100
            Re: Reference Alister <alister.ware@ntlworld.com> - 2014-03-04 11:10 +0000
              Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 11:48 +0000
                Re: Reference "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-05 00:25 +0000
      Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-03 15:51 -0600
      Re: Reference Jerry Hill <malaclypse2@gmail.com> - 2014-03-03 17:02 -0500
        Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 00:22 +0200
          Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-04 09:27 +1100
          Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 09:33 +1100
          Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 04:52 +0000
            Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-04 16:24 +1100
              Re: Reference "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-05 01:08 +0000
                Re: Reference Roy Smith <roy@panix.com> - 2014-03-04 21:09 -0500
                  Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 19:36 -0800
                    Re: Reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-04 21:08 -0700
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 20:31 -0800
                    Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 15:32 +1100
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 20:47 -0800
                    Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-05 05:06 +0000
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 21:47 -0800
                        Re: Reference alex23 <wuwei23@gmail.com> - 2014-03-05 16:01 +1000
                          Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 22:10 -0800
                            Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:22 +1100
                            Re: Reference alex23 <wuwei23@gmail.com> - 2014-03-05 16:28 +1000
                              Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 12:24 +0000
                            Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 12:21 +0000
                        Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:20 +1100
                          Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-05 09:40 -0800
                            Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-05 12:12 -0600
                            Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 05:33 +1100
                        Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-05 18:19 +0000
                          Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 22:23 +0200
                            Re: Reference Grant Edwards <invalid@invalid.invalid> - 2014-03-05 20:31 +0000
                              Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 22:46 +0200
                                Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:07 +1100
                                Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:10 +1100
                                Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 21:34 +0000
                                Re: Reference Terry Reedy <tjreedy@udel.edu> - 2014-03-05 18:00 -0500
                            Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-06 03:01 +0000
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 22:03 -0800
                        Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:26 +1100
                        Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 17:32 +1100
                        Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-05 08:24 -0600
                        Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-05 18:29 +0000
                          Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 22:34 +0200
                            Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:01 +1100
                              Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 23:14 +0200
                                Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-06 08:26 +1100
                                  Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 23:50 +0200
                                  Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-06 00:35 +0000
                                    Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-06 11:50 +1100
                                    Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-06 17:46 +0000
                                Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-05 15:33 -0600
                                Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:37 +1100
                                  Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-06 02:52 +0200
                                    Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 12:05 +1100
                                    Re: Reference alex23 <wuwei23@gmail.com> - 2014-03-06 12:12 +1000
                                Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 21:46 +0000
                    Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 08:23 +0200
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 22:33 -0800
                        Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:40 +1100
                      Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 12:35 +0000
                      Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 23:45 +1100
            Re: Reference Jerry Hill <malaclypse2@gmail.com> - 2014-03-04 10:19 -0500
              Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 15:42 +0000
                Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 03:02 +1100
                  Re: Reference Roy Smith <roy@panix.com> - 2014-03-04 11:14 -0500
                Re: Reference MRAB <python@mrabarnett.plus.com> - 2014-03-04 17:12 +0000
              Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 08:24 -0800
            Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 02:25 +1100
            Re: Reference Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-05 14:37 +0100
        Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 03:59 +0000
      Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 09:17 +1100
        Re: Reference Roy Smith <roy@panix.com> - 2014-03-03 18:02 -0500
          Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-04 10:09 +1100
          Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 04:38 +0000
    Re: Reference Terry Reedy <tjreedy@udel.edu> - 2014-03-03 13:48 -0500
      Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 03:45 +0000
      Re: Reference Alexander Blinne <news@blinne.net> - 2014-03-04 13:55 +0100
        Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 01:06 +1100
          Re: Reference Alexander Blinne <news@blinne.net> - 2014-03-04 22:53 +0100
            Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 09:01 +1100

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#67868

Rustom Mody <rustompmody@gmail.com> writes:

> On Wednesday, March 5, 2014 11:50:46 AM UTC+5:30, Ben Finney wrote:
> > So, what machine represenatation is leaked?
>
> > I'll re-iterate that "memory location of the object" isn't a valid
> > response. There is no necessary relation between the memory location of
> > the object referenced by "foo" and the return value of 'id(foo)'.
>
> ... however you are both disagreeing with me and also saying Ive not
> given the answer and further disagreeing with the python standard,
> which I quote:
>
> Every object has an identity, a type and a value. An object's identity
> never changes once it has been created; you may think of it as the
> object's address in memory. The 'is' operator compares the identity of
> two objects; the id() function returns an integer representing its
> identity (currently implemented as its address).
>
> from http://docs.python.org/2/reference/datamodel.html

Right. None of which constitutes a leaking abstraction. I'll repeat the
point: the abstraction does not leak if the user of that abstraction has
no need to deal with what lies beneath it.

In other words: A helpful “you may think of it as the object's address
in memory” does not constitute a leaky abstraction, because it would be
just as correct to say “you may think of it as a snowflake”.

There is no need for the user of the abstraction “object identity” to
know anything about the object's location in memory (nor of snowflakes),
nor ever to think about it when using the abstraction. You may, as the
documentation suggests, think of it that way; but you may also think of
it as anything else which agrees with the abstraction.

The clause about “object's location in memory” is not normative, does
not matter for using the abstraction, and is not part of the definition.
It literally does not matter for the purpose of using the abstraction,
so there's no leak.

In fact, in the current Python documentation the description has changed:

    Every object has an identity, a type and a value. An object’s
    identity never changes once it has been created; you may think of it
    as the object’s address in memory. The ‘is‘ operator compares the
    identity of two objects; the id() function returns an integer
    representing its identity.

    CPython implementation detail: For CPython, id(x) is the memory
    address where x is stored.

    <URL:http://docs.python.org/3/reference/datamodel.html>

So it's now even clearer that “memory address where the object is
stored” is *not* part of the abstraction, is *not* guaranteed to be what
‘id(foo)’ returns, and is an implementation detail of one particular
implementation, that can be ignored.

The abstraction “object identity” behaves exactly as the documentation
says it does, in the absence of any “object address in memory” concept,
and this is not undermined by suggestions that the reader may already
have a concept in mind which can help them to imagine the abstraction.

> So when you say
> > I'll re-iterate that "memory location of the object" isn't a valid
> > response. 
>
> well... all I can say is I dont know what to say :-)

I'd encourage you to read the documentation for comprehension. Not every
word in a discussion of a concept must be normative.

I'd also encourage you to report a bug, suggesting a documentation
improvement if you have been misled by (the latest version of) the
language reference.

-- 
 \        “Of course, everybody says they're for peace. Hitler was for |
  `\      peace. Everybody is for peace. The question is: what kind of |
_o__)                                peace?” —Noam Chomsky, 1984-05-14 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#67866

On Tue, 04 Mar 2014 21:47:21 -0800, Rustom Mody wrote:

> On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:
> 
>> > Python's 'is' leaks
>> > the machine abstraction. 'id' does it legitimately (somewhat), 'is'
>> > does it illegitimately
> 
>> and then later in another post:
> 
>> > "is" in python leaks machine representations into the otherwise clean
>> > HLL abstraction in python
> 
>> Rather than respond with incredulity and declare that you have no idea
>> what you are talking about, I'll give you the benefit of the doubt, and
>> accept the possibility that I am wrong, or possibly misunderstanding
>> you.
> 
> Umm...
> I guess my language was sloppy (a bit) A machine is ultimately also an
> abstraction -- What is firmware/microcode? Is it a virtual machine? etc
> Lets leave that however and just take 'machine' as a given.
> 
> Using machines as given, we build reprs for our (programmer's) data
> structures
> 
> So data structures are abstractions that have two 'faces' -- the
> machine-facing and the programmer-facing

What you are describing is normally called the implementation and the 
interface.


> For clarity of expression (and where you perhaps found me sloppy?? not
> sure...) its best to call the machine-face 'a representation' and the
> programmer-face 'an abstraction'

Only if you wish to ignore the standard terminology used by the rest of 
the computing world, and furthermore re-define the term "abstraction".


> Clearly this is a programmer-biased viewpoint. A hardware engineer would
> see things differently. As would the user of the app the programmer
> programs.

This doesn't seem to be relevant.


> Which is why to use the locution "is" without appropriate framing is
> philosopical is a pretension to a 'God's-eye-view'. If you are privy to
> such a viewpoint I'd be interested to know But for the rest of us who
> are not, its good to remember there are only perspectives no absolute
> truth.

And this appears to be meaningless. The best I can come up with is that 
you're concerned about the philosophical implications of stating that 
object x is object y.

Quite frankly, I think that's silly. Such concerns about identity of 
physical entities in the real world are *irrelevant*. You seem to be 
making a category mistake: the word "is" has certain meanings in plain 
English, with associated philosophical problems, therefore the Python 
"is" operator must have exactly the same meanings and problems. But this 
is as silly as thinking that we should be able to use a computer file to 
cut through metal, or that equality between 1+1 and 2 is a question of 
human rights.

The "is" operator has a well-defined meaning in Python. The "axe of my 
grandfather" paradox does not apply to the "is" operator. That definition 
in Python is very simple: the "is" operator returns True if the two 
operands are the same object, and false if they are different objects.

> That python is a hll means that machine reprs are intended to be
> abstracted away. 'is' fails to do that -- proof of that being the
> discrepancy between is and ==

There is no discrepancy between "is" and ==, since they are different 
operators with different semantics. You might as well claim that there is 
a discrepancy between + and * because 5+7 and 5*7 return different 
answers.


>> Can you explain what machine representations are leaked into Python by
>> the is operator?
> 
>> Do you see this as an accident of implementation, a bug that might be
>> fixed, or a misfeature that was deliberately designed?
> 
>> Can you elaborate on why id() is legitimate and "is" is not?
> 
> Let me talk of Lisp which is IMHO more philosophically sane. 

I'd rather you answer the questions I asked rather than change the 
subject to an irrelevance.

[...]
> Decide the viewpoint  -- choose the appropriate equivence predicate No
> claim even remotely to having a clue to metaphysical being that python's
> 'is' implies

There is no metaphysical implication from Python's "is" operator. If the 
operator had precisely the same behaviour, but was called "same", as in:

a same b
=> returns True if a and b are the same object
=> returns False if a and b are not the same object

would you claim there was a metaphysical implication?

How about if it were called "eq", like Lisp uses?



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#67872

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> There is no metaphysical implication from Python's "is" operator. If the 
> operator had precisely the same behaviour, but was called "same", as in:
>
> a same b
> => returns True if a and b are the same object
> => returns False if a and b are not the same object
>
> would you claim there was a metaphysical implication?

I would. You are not defining anything because you are not explaining
what "same object" means.

Set theory obeys the so-called extensionality principle: if two objects
are indistinguishable in every way, they are one and the same object.
Fermions in particle physics are the same way: if two fermions' quantum
states coincide, they are one and the same particle.

Now, that's not true for Pythons "bosonic" objects. You can have two
objects that are identical except they are not the same.

There are (at least) two ways to break the circularity between "is" and
"same-objectness:"

  1. Give a real or hypothetical reference implementation and state that
     any other implementation that produces same (or similar enough)
     outcomes is valid. ("Each object is allocated with the malloc(3)
     function call. The identity of an object is the value returned by
     malloc(3).")

  2. Give formal axioms that characterize any valid implementation.
     ("After x = y, x is y" plus a couple of dozen more formal
     stipulations.)


As for teaching the concept in practice, both of the above approaches
are probably bad. Take abstract algebra. You don't start teaching a
first-grader about groups and rings and work your way down to
arithmetics. Rather, you start with counting, move on to arithmetics,
bring in vectors and maybe Rubik's Cube and finally try to get the
students to understand the general, abstract idea behind it all.

Analogously, it may be necessary to teach the "children" first the
theory of linear memory, then variables and arrays, then pointers and
singly-linked lists. Once these concrete ideas have been understood, the
principles behind Python and other higher-level programming languages
can be learned.

> How about if it were called "eq", like Lisp uses?

You are correct. Lisp suffers from the same problem. The underlying
reference machine is simpler to present, though, as there are no classes
or methods. There are only memory cells and a handful of data types
(number, cons, symbol, string or nil). You really get a feel of a
physical steam engine.

Ten years ago a whole generation of programmers was raised who knew
nothing of computing except Java. I wonder how difficult it was for them
to get objects, references and identity.


Marko

[toc] | [prev] | [next] | [standalone]

#67873

On 2014-03-05, Marko Rauhamaa <marko@pacujo.net> wrote:

> Set theory obeys the so-called extensionality principle: if two
> objects are indistinguishable in every way, they are one and the same
> object. Fermions in particle physics are the same way: if two
> fermions' quantum states coincide, they are one and the same
> particle.
>
> Now, that's not true for Pythons "bosonic" objects. You can have two
> objects that are identical except they are not the same.

Wrong.  If the two objects are not the same, then they will have
different ID values.  If the ID values are the same, then you've only
got one object.

Two different objects are always distinguishable in Python because
they will always have different ID values.

> There are (at least) two ways to break the circularity between "is" and
> "same-objectness:"

I'm sorry, what problem are you trying to solve?

-- 
Grant Edwards               grant.b.edwards        Yow! I'm definitely not
                                  at               in Omaha!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#67875

Grant Edwards <invalid@invalid.invalid>:

> Wrong. If the two objects are not the same, then they will have
> different ID values. If the ID values are the same, then you've only
> got one object.

Ok, that circularity again.

Say I implement Python. Say I returned a random number for id(), how
would that violate the language spec?

It would violate the spec. But there would have to be a paragraph in the
specification that was violated or a reference test case that failed.

For example, this test would demonstrate obviously invalid behavior:

   >>> print(id(x))
   129
   >>> print(id(x))
   201

> I'm sorry, what problem are you trying to solve?

I think the discussion spawned from the problem of teaching programming
students the right idea of values and objects. A teacher would like to
bring in advanced concepts last, but Python seems to force you to get
them at the very beginning.


Marko

[toc] | [prev] | [next] | [standalone]

#67878

Marko Rauhamaa <marko@pacujo.net> writes:

> Say I implement Python. Say I returned a random number for id(), how
> would that violate the language spec?

You could do that, certainly. So long as that randomly-chosen integer
was always the same for every object, and never the same for any other
concurrently-existing object, it can just as well be assigned randomly.

If you're saying that your implementation of ‘id(foo)’ would return a
*different* integer when called at different times for the same object,
then yes, that violates the specification for that function.

> It would violate the spec. But there would have to be a paragraph in
> the specification that was violated or a reference test case that
> failed.

Yes. It would violate this paragraph:

    Every object has an identity, a type and a value. An object’s
    identity never changes once it has been created […] the id()
    function returns an integer representing its identity.

    <URL:http://docs.python.org/3/reference/datamodel.html>

Again, I ask you to read these documents for comprehension.

> For example, this test would demonstrate obviously invalid behavior:
>
>    >>> print(id(x))
>    129
>    >>> print(id(x))
>    201

Yes. That violates the paragraph above, and so that implementation is
not compliant with the Python language reference.

-- 
 \       “I watched the Indy 500, and I was thinking that if they left |
  `\         earlier they wouldn't have to go so fast.” —Steven Wright |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#67880

Marko Rauhamaa <marko@pacujo.net> writes:

> Grant Edwards <invalid@invalid.invalid>:
>
> > Wrong. If the two objects are not the same, then they will have
> > different ID values. If the ID values are the same, then you've only
> > got one object.
>
> Ok, that circularity again.

Yes, it's circular. In an abstract system like a programming language,
where the definition only needs to describe behaviour of that system,
what is your objection to circularity of definition?

A great many abstract systems designed by humans are defined in terms
that are ultimately circular. This does not in any way hinder them from
being useful definitions of useful systems.

-- 
 \        “All opinions are not equal. Some are a very great deal more |
  `\    robust, sophisticated and well supported in logic and argument |
_o__)                                     than others.” —Douglas Adams |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#67884

On 05/03/2014 20:46, Marko Rauhamaa wrote:
>
> I think the discussion spawned from the problem of teaching programming
> students the right idea of values and objects. A teacher would like to
> bring in advanced concepts last, but Python seems to force you to get
> them at the very beginning.
>

Nonsense, people starting out with Python have stated how easy it is to 
just start writing Python code.  This would obviously not be possible if 
advanced concepts had to be learned up front.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#67894

On 3/5/2014 3:46 PM, Marko Rauhamaa wrote:
> Grant Edwards <invalid@invalid.invalid>:
>
>> Wrong. If the two objects are not the same, then they will have
>> different ID values. If the ID values are the same, then you've only
>> got one object.
>
> Ok, that circularity again.

Every deductive system starts with some undefined terms. These, along 
with axioms or postulates, are how circularity is avoided. There 
typically is a choice as to which concepts are taken as primitive and 
which are defined in terms of them. In Python, one could take 'object' 
and the notions of same versus different object as primitive.

> Say I implement Python. Say I returned a random number for id(),

In CPython, the int id of an object is arbitrary, somewhat haphazard, 
and effectively random in the colloquial sense of the term.

 > how would that violate the language spec?

It obviously does not as long as the 'random' id obeys the id axioms of 
persistence and uniqueness.

> I think the discussion spawned from the problem of teaching programming
> students the right idea of values and objects. A teacher would like to
> bring in advanced concepts last, but Python seems to force you to get
> them at the very beginning.

Kids learn the notion of object persistence quite early (first year, I 
think). Kids also learn that there are multiple ways of referring to one 
and the same person or object, and that some references ('teacher') can 
be rebound to a different person or object.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#67913

On Wed, 05 Mar 2014 22:23:46 +0200, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> There is no metaphysical implication from Python's "is" operator. If
>> the operator had precisely the same behaviour, but was called "same",
>> as in:
>>
>> a same b
>> => returns True if a and b are the same object => returns False if a
>> and b are not the same object
>>
>> would you claim there was a metaphysical implication?
> 
> I would. You are not defining anything because you are not explaining
> what "same object" means.

I mean exactly the same thing by "same object" as you do when you use it:

> Set theory obeys the so-called extensionality principle: if two objects
> are indistinguishable in every way, they are one and the same object.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#67807

On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:

> > Python's 'is' leaks
> > the machine abstraction. 'id' does it legitimately (somewhat), 'is' does
> > it illegitimately


> Can you elaborate on why id() is legitimate and "is" is not?

Mostly a question of more or less infelicitous English leading to philosophical
nonsense. [And note I put a 'somewhat']

I can say "'id' is just 'machine-id' is just address at some low level"

Its uglier to say "Is is machine-is"

And before you bring it up, "Jython's id is not machine-id" is putting
the cart before the horse.

"Jython is an imitation of Cpython and does a good job but not quite as
in the case of 'id'"

is the right order (IMHO)

[toc] | [prev] | [next] | [standalone]

#67813

Rustom Mody <rustompmody@gmail.com> writes:

> I can say "'id' is just 'machine-id' is just address at some low
> level"

You could say that, but it's wrong. The only thing promised by “object
identity” is that each object has it, and that it is different from the
identity of every other object concurrently existing.

“Machine id” is not entailed within that at all.

> And before you bring it up, "Jython's id is not machine-id" is putting
> the cart before the horse.

You have a false idea of what Python's object identity means, and it has
warped your understanding of what implementations do.

> "Jython is an imitation of Cpython and does a good job but not quite as
> in the case of 'id'"

Wrong. Jython and CPython both adhere to the guarantees of object
identity. Both implementations follow the language reference, and
neither implementation does object identity better or worse than the
other.

-- 
 \       “Science shows that belief in God is not only obsolete. It is |
  `\                        also incoherent.” —Victor J. Stenger, 2001 |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#67814

On Wed, Mar 5, 2014 at 5:03 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> I can say "'id' is just 'machine-id' is just address at some low level"

And I can say that "id" returns a list of digits, but that doesn't
make either statement true.

The id() function returns a number which (a) never changes for any
given object, and (b) will never be the same for any two
concurrently-existing objects. It's a proxy for object identity.
That's all.

ChrisA

[toc] | [prev] | [next] | [standalone]

#67850

On 2014-03-05 17:26, Ben Finney wrote:
> > "Jython is an imitation of Cpython and does a good job but not
> > quite as in the case of 'id'"  
> 
> Wrong. Jython and CPython both adhere to the guarantees of object
> identity. Both implementations follow the language reference, and
> neither implementation does object identity better or worse than the
> other.

I think he means "but not quite as [good in making my argument,
despite the fact that the language definition runs contrary to my
mistaken belief] as in [my interpretation of] 'id'"

:-)


-tkc

[toc] | [prev] | [next] | [standalone]

#67867

On Tue, 04 Mar 2014 22:03:36 -0800, Rustom Mody wrote:

> On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:
> 
>> > Python's 'is' leaks
>> > the machine abstraction. 'id' does it legitimately (somewhat), 'is'
>> > does it illegitimately
> 
> 
>> Can you elaborate on why id() is legitimate and "is" is not?
> 
> Mostly a question of more or less infelicitous English leading to
> philosophical nonsense. [And note I put a 'somewhat']

Well it is certainly true that this discussion has lead to philosophical 
nonsense from one of us.



> I can say "'id' is just 'machine-id' is just address at some low level"

You can say it, but you would be wrong.

I don't know how many times you have to be told. The id() function in 
Python is not defined as returning the address of the object. There is no 
guarantee that objects even have a consistent, stable addresses. Some 
garbage collectors will move objects around. The Python language does not 
claim that the id() function will return the address of objects, it says 
that it will return an abstract ID number that is unique for that object 
while the object exists.


> Its uglier to say "Is is machine-is"
> And before you bring it up, "Jython's id is not machine-id" is putting
> the cart before the horse.
> 
> "Jython is an imitation of Cpython

That's wrong. Jython is not an imitation, it is an independent 
implementation of the same language. Since both CPython and Jython follow 
the specification of the language, both are legitimate Python compilers. 

Both the Jython and CPython id() functions are compliant with the 
language definition. The Jython id() function is better, because it 
doesn't encourage people to mistakenly and foolishly imagine that id() 
equals address.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#67874

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> The id() function in Python is not defined as returning the address of
> the object.

It might as well. If I said id() returns the address of the object in
the Python VM's virtual address space, you couldn't call my bluff.

Say id() returned the intantiation sequence number. I could say, the
infinite linear memory starts from address 0 and each object occupies a
single memory slot.

> That's wrong. Jython is not an imitation, it is an independent
> implementation of the same language. Since both CPython and Jython
> follow the specification of the language, both are legitimate Python
> compilers.
>
> Both the Jython and CPython id() functions are compliant with the
> language definition. The Jython id() function is better, because it
> doesn't encourage people to mistakenly and foolishly imagine that id()
> equals address.

I agree with everything (how could I not) except the foolishness part:
what bad consequence is there for "imagining" that id() equals address?
If id() offers the only glimpse into the "memory," we can say that id()
*is* the address.


Marko

[toc] | [prev] | [next] | [standalone]

#67877

Marko Rauhamaa <marko@pacujo.net> writes:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> > Both the Jython and CPython id() functions are compliant with the
> > language definition. The Jython id() function is better, because it
> > doesn't encourage people to mistakenly and foolishly imagine that
> > id() equals address.
>
> I agree with everything (how could I not) except the foolishness part:
> what bad consequence is there for "imagining" that id() equals
> address?

It is a false inference.

A reference-compliant implementation can contradict your inference (by
returning an object identity that is *not* the object's memory address).
Any code you've written based on that false inference will break.

The fault will be yours, for inferring an assertion that isn't implied
by the definition.

-- 
 \       “The surest way to corrupt a youth is to instruct him to hold |
  `\       in higher esteem those who think alike than those who think |
_o__)             differently.” —Friedrich Nietzsche, _The Dawn_, 1881 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#67879

Ben Finney <ben+python@benfinney.id.au>:

> A reference-compliant implementation can contradict your inference (by
> returning an object identity that is *not* the object's memory
> address). Any code you've written based on that false inference will
> break.
>
> The fault will be yours, for inferring an assertion that isn't implied
> by the definition.

Show me a few lines of Python that demonstrate the error of the false
inference, please.

When I talk about an object's memory address, I'm not referring to what
might be revealed by gdb, for example. That is, I'm not talking about
the process's virtual address space, nor am I talking about the physical
address on the address bus. I can simply define that the object's memory
address is whatever id() returns.


Marko

[toc] | [prev] | [next] | [standalone]

#67882

On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> When I talk about an object's memory address, I'm not referring to what
> might be revealed by gdb, for example. That is, I'm not talking about
> the process's virtual address space, nor am I talking about the physical
> address on the address bus. I can simply define that the object's memory
> address is whatever id() returns.

Where's the complaints about circularity now? You're saying "But of
course id() returns the address, as long as we define the address as
'whatever id() returns'.". Unimpeachably logical and utterly
unhelpful.

ChrisA

[toc] | [prev] | [next] | [standalone]

#67888

Chris Angelico <rosuav@gmail.com>:

> On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> When I talk about an object's memory address, I'm not referring to
>> what might be revealed by gdb, for example. That is, I'm not talking
>> about the process's virtual address space, nor am I talking about the
>> physical address on the address bus. I can simply define that the
>> object's memory address is whatever id() returns.
>
> Where's the complaints about circularity now? You're saying "But of
> course id() returns the address, as long as we define the address as
> 'whatever id() returns'.". Unimpeachably logical and utterly
> unhelpful.

Main thing, no harm done.

The memory address is neither right nor wrong. It's completely
irrelevant since it doesn't occupy a place in Python's data model.


Marko

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web