Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #66310 > unrolled thread
| Started by | dave em <daveandem2000@gmail.com> |
|---|---|
| First post | 2014-02-14 10:08 -0800 |
| Last post | 2014-02-16 09:27 +1100 |
| Articles | 20 on this page of 136 — 23 participants |
Back to article view | Back to comp.lang.python
Explanation of list reference dave em <daveandem2000@gmail.com> - 2014-02-14 10:08 -0800
Re: Explanation of list reference Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-14 20:26 +0200
Re: Explanation of list reference dave em <daveandem2000@gmail.com> - 2014-02-14 10:54 -0800
Re: Explanation of list reference Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-14 19:20 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 21:56 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-14 13:17 -0700
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 22:58 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 08:16 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 23:43 +0200
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-14 19:00 -0500
Re: Explanation of list reference dave em <daveandem2000@gmail.com> - 2014-02-14 16:26 -0800
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:07 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 11:00 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 11:57 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 17:55 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 13:08 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 18:34 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 13:42 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 19:14 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 14:33 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 20:24 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 15:37 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:54 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 18:19 +1100
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-14 22:20 -0700
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 07:03 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 16:31 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 22:07 -0800
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-15 17:19 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 22:31 -0800
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 17:23 +1100
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 01:08 -0700
Re: Explanation of list reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-15 12:42 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 15:44 +0200
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-16 06:00 -0800
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-16 11:29 -0500
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-16 08:50 -0800
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 20:01 +0200
Re: Explanation of list reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-16 18:36 +0000
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 05:52 +0000
Re: Explanation of list reference Terry Reedy <tjreedy@udel.edu> - 2014-02-15 15:40 -0500
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 02:27 +0000
Re: Explanation of list reference Grant Edwards <invalid@invalid.invalid> - 2014-02-15 19:02 +0000
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:44 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 18:05 +1100
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 00:29 +1300
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:15 +0000
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-14 22:24 -0800
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 00:32 +1300
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:37 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 11:10 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 10:31 +0000
Re: Explanation of list reference Christian Gollwitzer <auriocus@gmx.de> - 2014-02-15 10:44 +0100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 12:10 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 10:53 +0000
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-17 11:40 +1300
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 05:57 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:21 +1100
Re: Explanation of list reference Alister <alister.ware@ntlworld.com> - 2014-02-16 19:16 +0000
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-15 15:20 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 11:31 +0200
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 12:13 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 11:17 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 14:07 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 14:41 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 18:29 +0200
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-15 12:02 -0500
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-15 09:30 -0800
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 11:37 -0700
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 11:45 -0700
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 19:05 +0000
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 10:11 -0700
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 22:20 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-15 14:20 -0700
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-15 09:47 -0800
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 19:17 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 23:01 +0200
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 02:25 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 13:18 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:31 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 10:40 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 22:17 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-14 23:20 +0200
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 10:08 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-16 01:28 -0700
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 12:52 +0200
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 22:24 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 12:04 +0000
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-16 18:17 +0200
Re: Explanation of list reference Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-16 10:35 +0200
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-16 01:35 -0700
Re: Explanation of list reference Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-02-16 03:38 -0500
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-16 08:40 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 21:18 +1100
Re: Explanation of list reference Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-16 12:10 -0500
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-14 15:45 -0500
Re: Explanation of list reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-14 13:12 -0700
Re: Explanation of list reference Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-14 22:36 +0200
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 01:03 +1300
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-15 23:21 +1100
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-14 13:42 -0500
Re: Explanation of list reference Ryan Gonzalez <rymg19@gmail.com> - 2014-02-14 12:31 -0600
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 05:36 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 17:07 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-15 06:48 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 17:57 +1100
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-16 01:18 +1300
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-15 23:24 +1100
Re: Explanation of list reference Marko Rauhamaa <marko@pacujo.net> - 2014-02-15 15:25 +0200
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-16 00:59 +1100
Re: Explanation of list reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-02-17 11:54 +1300
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 10:02 +1100
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-16 18:46 -0500
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 12:26 +1100
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-17 10:05 +1100
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-16 18:43 -0500
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-17 11:04 +1100
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 06:31 +0000
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-17 05:43 -0800
Re: Explanation of list reference Ned Batchelder <ned@nedbatchelder.com> - 2014-02-16 20:43 -0500
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 12:59 +1100
Re: Explanation of list reference Roy Smith <roy@panix.com> - 2014-02-16 22:28 -0500
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-17 14:52 +1100
Re: Explanation of list reference Rustom Mody <rustompmody@gmail.com> - 2014-02-16 20:35 -0800
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 08:03 +0000
Re: Explanation of list reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-17 06:21 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-17 18:11 +1100
Re: Explanation of list reference Rotwang <sg552@hotmail.co.uk> - 2014-02-17 18:24 +0000
Re: Explanation of list reference Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-02-15 14:30 -0500
Re: Explanation of list reference Terry Reedy <tjreedy@udel.edu> - 2014-02-14 16:37 -0500
Re: Explanation of list reference pecore@pascolo.net - 2014-02-14 23:34 +0100
Re: Explanation of list reference Christian Gollwitzer <auriocus@gmx.de> - 2014-02-15 10:38 +0100
Re: Explanation of list reference Ben Finney <ben+python@benfinney.id.au> - 2014-02-16 01:20 +1100
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 01:26 +1100
Re: Explanation of list reference Joshua Landau <joshua@landau.ws> - 2014-02-15 20:44 +0000
Re: Explanation of list reference Chris Angelico <rosuav@gmail.com> - 2014-02-16 09:27 +1100
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 11:31 +0200 |
| Message-ID | <87y51cn2m9.fsf@elektro.pacujo.net> |
| In reply to | #66360 |
Ben Finney <ben+python@benfinney.id.au>: > You should never need to predict the result of an ‘is’ operation. > (More precisely, for *some* cases you can predict it, but for other > cases you can't.) No problem there. You have to understand "is" well to use it. Referring to "objects in memory" when defininig "is" leads to circular definitions. It think the best way to define the semantics of "is" is through constraints: 1. if x is y then y ix x 2. if x is y and y is z then x is z 3. after x = y, x is y 4. if x is y, then x == y That's why "is" is not introductory material. The constraints define a relation that coincides with == wherever it is defined. So why would you ever use "is" instead of "=="? After all, all well-defined programs would behave identically after replacing "is" with "==". Really, the only reason would be performance; "is" is often faster to evaluate than "==". Marko
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 12:13 +0200 |
| Message-ID | <87mwhsn0nx.fsf@elektro.pacujo.net> |
| In reply to | #66397 |
Marko Rauhamaa <marko@pacujo.net>: > 1. if x is y then y ix x > 2. if x is y and y is z then x is z > 3. after x = y, x is y > 4. if x is y, then x == y A new attempt: 0. x is x 1. if x is y then y ix x 2. if x is y and y is z then x is z 3. after x = y, x is y 4. if x is y and x == x, then x == y 5. id(x) == id(y) iff x is y Does that cover it? Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 11:17 +0000 |
| Message-ID | <52ff4ce4$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66402 |
On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote: > Marko Rauhamaa <marko@pacujo.net>: > >> 1. if x is y then y ix x >> 2. if x is y and y is z then x is z >> 3. after x = y, x is y >> 4. if x is y, then x == y > > A new attempt: > > 0. x is x > 1. if x is y then y ix x > 2. if x is y and y is z then x is z > 3. after x = y, x is y > 4. if x is y and x == x, then x == y > 5. id(x) == id(y) iff x is y Python implementations are free to re-use IDs after the object is destroyed. CPython does; Jython and IronPython do not. So #5 needs to point out that the condition id(x) == id(y) only applies if x and y still exist. # Counter-example py> x = 230000 py> idx = id(x) py> del x py> y = 420000 py> idy = id(y) py> idx == idy True (This is *implementation dependent* so your mileage my vary.) > Does that cover it? No. Your definition describes some properties of identity-equivalence, but doesn't explain what identity actually means. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 14:07 +0200 |
| Message-ID | <87iosgmveg.fsf@elektro.pacujo.net> |
| In reply to | #66411 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote: >> 0. x is x >> 1. if x is y then y ix x >> 2. if x is y and y is z then x is z >> 3. after x = y, x is y >> 4. if x is y and x == x, then x == y >> 5. id(x) == id(y) iff x is y > > # Counter-example > py> x = 230000 > py> idx = id(x) > py> del x > py> y = 420000 > py> idy = id(y) > py> idx == idy > True I don't accept that as a counterexample. You will have to produce: (id(x) == id(y)) == (x is y) > False > (This is *implementation dependent* so your mileage my vary.) > >> Does that cover it? > > No. Your definition describes some properties of identity-equivalence, > but doesn't explain what identity actually means. That's the point. I don't think id() and "is" have any abstract meaning on top of the formal axioms. Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 14:41 +0000 |
| Message-ID | <52ff7cac$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66423 |
On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote: > Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > >> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote: >>> 0. x is x >>> 1. if x is y then y ix x >>> 2. if x is y and y is z then x is z >>> 3. after x = y, x is y >>> 4. if x is y and x == x, then x == y >>> 5. id(x) == id(y) iff x is y >> >> # Counter-example >> py> x = 230000 >> py> idx = id(x) >> py> del x >> py> y = 420000 >> py> idy = id(y) >> py> idx == idy >> True > > I don't accept that as a counterexample. Why? Do you think I lied and just faked the output I put into my post? It is a clear case where two distinct objects, in this case 230000 and 420000, have the same ID. You cut out the explanation I gave explaining the example, which is crucial. Your description of identity leaves out a critical factor, namely that the objects being discussed must exist simultaneously. If you don't specify that factor, your description includes a great big hole, just as I show above. > You will have to produce: > > (id(x) == id(y)) == (x is y) > > False I don't have to produce anything of the sort. All I need to do is show a case where two distinct objects have the same ID. That is quite easy in CPython, since IDs can be re-used after objects are garbage-collected. >> (This is *implementation dependent* so your mileage my vary.) >> >>> Does that cover it? >> >> No. Your definition describes some properties of identity-equivalence, >> but doesn't explain what identity actually means. > > That's the point. I don't think id() and "is" have any abstract meaning > on top of the formal axioms. Who is talking about "abstract meaning"? They have concrete meaning in Python, and extremely simple meaning at that. * id() is a function which returns an abstract implementation- dependent identity number which is unique for each object during the object's lifetime. * The "is" operator compares the two operands for identity, returning True if, and only if, they are the same object, otherwise returning False. Object identity is simple and well-defined in Python. I don't know why you are so resistant to this. Read the documentation. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 18:29 +0200 |
| Message-ID | <87wqgwl4oo.fsf@elektro.pacujo.net> |
| In reply to | #66444 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote: >> Steven D'Aprano <steve+comp.lang.python@pearwood.info>: >>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote: >>>> 5. id(x) == id(y) iff x is y >>> >>> # Counter-example >>> py> x = 230000 >>> py> idx = id(x) >>> py> del x >>> py> y = 420000 >>> py> idy = id(y) >>> py> idx == idy >>> True >> >> I don't accept that as a counterexample. > Why? Nowhere do I see the violating "x is y". > All I need to do is show a case where two distinct objects have the > same ID. How do you know objects are "distinct"? Myself, I would use the "is" test. >> That's the point. I don't think id() and "is" have any abstract >> meaning on top of the formal axioms. > > Who is talking about "abstract meaning"? I am. I mean, "implementation-independent". > Object identity is simple and well-defined in Python. I don't know why > you are so resistant to this. Read the documentation. It is not defined at all: 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. Thus "x and y are identical" *means* "x is y" and nothing else. Marko
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-02-15 12:02 -0500 |
| Message-ID | <roy-1F7312.12023915022014@news.panix.com> |
| In reply to | #66454 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > > Object identity is simple and well-defined in Python. I don't know why > > you are so resistant to this. Read the documentation. Marko Rauhamaa <marko@pacujo.net>: > It is not defined at all: > > 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. The "you may think of it as the object's address in memory" part is misleading, and should be removed from the docs. While it's true that you may think of it that way, such thinking just leads you to make assumptions which are not universally true. I agree with Marko that this is not a definition. It's a collection of random statements about ids, their use, and some misleading philosophy. Even the part about "... compares the identify of two objects" is kind of funky, since it implies that you do indeed have two objects! A definition would be: "The identity of an object is an integer which never changes during the lifetime of the object, and which is guaranteed to be distinct from the identities of all other objects with overlapping lifetimes. A given identity may be reused for objects with disjoint lifetimes". That (I think) says everything is which is guaranteed about identities, and nothing more. Once you've defined what an identity is, then you can go on to describe some fun things you can do with it: "The id() function returns the identity of an object. The 'is' operator compares the identities of its two operands and returns True if they are the same."
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-15 09:30 -0800 |
| Message-ID | <c176e37d-6fc8-4fb6-9bd4-0819c5dacabb@googlegroups.com> |
| In reply to | #66456 |
On Saturday, February 15, 2014 10:32:39 PM UTC+5:30, Roy Smith wrote: > Steven D'Aprano : > > > Object identity is simple and well-defined in Python. I don't know why > > > you are so resistant to this. Read the documentation. > Marko Rauhamaa > > It is not defined at all: > > 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. > The "you may think of it as the object's address in memory" part is > misleading, and should be removed from the docs. While it's true that > you may think of it that way, such thinking just leads you to make > assumptions which are not universally true. > I agree with Marko that this is not a definition. It's a collection of > random statements about ids, their use, and some misleading philosophy. > Even the part about "... compares the identify of two objects" is kind > of funky, since it implies that you do indeed have two objects! > A definition would be: > "The identity of an object is an integer which never changes during the > lifetime of the object, and which is guaranteed to be distinct from the > identities of all other objects with overlapping lifetimes. A given > identity may be reused for objects with disjoint lifetimes". > That (I think) says everything is which is guaranteed about identities, > and nothing more. Once you've defined what an identity is, then you can > go on to describe some fun things you can do with it: Thanks! -- Nice to hear slightly more philosophically astute attempt than the naivete going around: "Object?! We all know whats an object! Everyone knows whats an object!!" However I am betting that the problem remains. Youve transfered the identity question into the lifetime. Now define object-lifetime without reference to identity :-) [Incidentally same applies to Ian's attempt at reducing identity to creation] Just staying with 'lifetime' and the original meaning from which this word was analogized. (Allegorized?) I am supposed to be about 50 years old. What exactly does that mean? The cells in my body recycle every few months -- couple of years if we add bones The molecules that make up those cells are as old as the universe. What exactly does that 50 refer to? > "The id() function returns the identity of an object. The 'is' operator > compares the identities of its two operands and returns True if they are > the same." Thats good -- 'is' in terms of 'id' -- better than the obfuscation and prevarication of the other way round. Only the name id is misleading -- it should be machine-id or some such. Consider these examples: Two graphs are the same if they have the same no of vertices and there is a mapping f from one vertex set to the other such that vw is edge in graph1 iff f(v)f(w) is edge in graph2. For a mathematician such an identity is unexceptionable The only catch is that implementing such an identity requires finding the f and that is NP complete. Even worse... Two functions f and g are the same (from a math pov) if ∀ x y . f(x) = g(y) Now I define def f(x) : return x+x def g(x) : return 2*x If a python (or any such) implementation could 'solve' f==g ∀ f,g, it could also 'solve' f == h where h is def h(x) : return h(x) which is the halting problem Moral? The meaning of identity is very dependent on framing and has no 'single' 'obvious' 'most natural' answer. Given that we are (hopefully!) programmers, a machine-oriented framing seems appropriate
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-15 11:37 -0700 |
| Message-ID | <mailman.7016.1392489500.18130.python-list@python.org> |
| In reply to | #66463 |
On Sat, Feb 15, 2014 at 10:30 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Thanks! -- Nice to hear slightly more philosophically astute attempt than
> the naivete going around: "Object?! We all know whats an object!
> Everyone knows whats an object!!"
>
> However I am betting that the problem remains. Youve transfered the identity
> question into the lifetime.
>
> Now define object-lifetime without reference to identity :-)
Fundamentally that's what definitions do. They transfer the question
of "what is X" to "okay, so what is this thing that defines X". All
definitions must ultimately be circular, simply because we have only
finitely many words and concepts to work with.
>> "The id() function returns the identity of an object. The 'is' operator
>> compares the identities of its two operands and returns True if they are
>> the same."
>
> Thats good -- 'is' in terms of 'id' -- better than the obfuscation and
> prevarication of the other way round. Only the name id is misleading -- it
> should be machine-id or some such.
>
> Consider these examples:
>
> Two graphs are the same if they have the same no of vertices and
> there is a mapping f from one vertex set to the other such that
> vw is edge in graph1 iff f(v)f(w) is edge in graph2.
>
> For a mathematician such an identity is unexceptionable
Is it though? If we were to play the same game with it, I could point
out that you haven't defined graph. So I'll retrieve a definition
from Wikipedia:
"""
a graph is an ordered pair G = (V, E) comprising a set V of vertices
or nodes together with a set E of edges or lines, which are 2-element
subsets of V
"""
Well, that's great, but it just transfers the definition of graph into
the definition of an ordered pair. Ordered pairs can be defined in
terms of sets:
"""
In 1921 Kazimierz Kuratowski offered the now-accepted definition of
the ordered pair (a, b):
(a, b) := {{a}, {a, b}}
"""
But what is a set? Cantor offers this definition:
"""
A set is a gathering together into a whole of definite, distinct
objects of our perception [Anschauung] or of our thought - which are
called elements of the set.
"""
But what precisely are "objects" and how are we to determine their
distinctness? Cantor above relates them to perception or thought, but
surely my own perception and thought differ from Cantor's. If
mathematics or philosophy offer us any absolute answer to this
question, I'm unable to find it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-15 11:45 -0700 |
| Message-ID | <mailman.7017.1392489996.18130.python-list@python.org> |
| In reply to | #66463 |
On Sat, Feb 15, 2014 at 11:37 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > But what is a set? Cantor offers this definition: > > """ > A set is a gathering together into a whole of definite, distinct > objects of our perception [Anschauung] or of our thought - which are > called elements of the set. > """ > > But what precisely are "objects" and how are we to determine their > distinctness? Cantor above relates them to perception or thought, but > surely my own perception and thought differ from Cantor's. If > mathematics or philosophy offer us any absolute answer to this > question, I'm unable to find it. I sent the last message a little too early. To continue: the above definition of set is an informal one. In axiomatic set theory, it turns out that "set" is simply taken as an undefined primitive. In other words: "Set?! We all know what's a set! Everyone knows what's a set!!" At some level we have to have primitives, and while we can at some level delve into the machine in order to define an object in terms of memory location and layout and lifetime and even physical considerations such as "which memory?"; at the level of the Python abstraction I suggest that an object is simply an undefined primitive.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 19:05 +0000 |
| Message-ID | <52ffba5f$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66456 |
On Sat, 15 Feb 2014 12:02:39 -0500, Roy Smith wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>> > Object identity is simple and well-defined in Python. I don't know
>> > why you are so resistant to this. Read the documentation.
>
> Marko Rauhamaa <marko@pacujo.net>:
>> It is not defined at all:
>>
>> 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.
>
> The "you may think of it as the object's address in memory" part is
> misleading, and should be removed from the docs. While it's true that
> you may think of it that way, such thinking just leads you to make
> assumptions which are not universally true.
>
> I agree with Marko that this is not a definition. It's a collection of
> random statements about ids, their use, and some misleading philosophy.
> Even the part about "... compares the identify of two objects" is kind
> of funky, since it implies that you do indeed have two objects!
Correct, it should say "two operands" to be pedantic.
But in regular English, it is quite normal to say things like "the two
people actually turned out to be same person" (say, Superman and Clark
Kent) and I see no reason not to allow the similar, technically sloppy
but easily understandable idea that the `is` operator tests whether two
objects are in fact the same object.
This concept isn't really that hard to understand. In the expression `a
is b`, you have an object bound to the name "a", an object bound to the
name "b", hence *two objects*, and you want to know if they are the same
object or not.
> A definition would be:
>
> "The identity of an object is an integer which never changes during the
> lifetime of the object, and which is guaranteed to be distinct from the
> identities of all other objects with overlapping lifetimes. A given
> identity may be reused for objects with disjoint lifetimes".
You then go on to say:
> "The id() function returns the identity of an object. ..."
This definition is wrong. An object's identity and its ID are not the
same. Objects in Python have an identity the instant they are created,
but they may not have an ID assigned to them until much later, if at all.
Both IronPython and Jython lazily assign IDs on request, not on creation.
Here's an example from Jython:
>>> x = "first"
>>> y = "second"
>>> id(y) # created second, but ID assigned first
1
>>> id(x) # created first, but ID assigned second
2
IronPython is similar, although the specific IDs may not be the same.
The problem here is that you are wrongly identifying an object's identity
with its identification number. That doesn't apply to people (if you are
American, your identity is not the same as your Social Security number);
it doesn't apply to rocks, or pencils, or kitchen spoons. Why should it
apply to Python objects? The identity of an object is an inherent,
fundamental aspect of the object's existence, not some label stuck to it.
In Jython, the `is` operator can distinguish objects without assigning
them an ID number:
>>> a = 230000
>>> b = 230000
>>> a is b # compare two ID-less objects for identity
False
>>> id("fe")
4
>>> id("fi")
5
>>> id(a) # finally assign a an ID
6
>>> id("fo")
7
>>> id(b) # and the same for b
8
In plain English, "identity" has various definitions, but the one needed
here is this:
The state or quality of being identical, or the same; sameness.
[Webster 1913]
where "identical" is understood in the strong sense of:
being the exact same one; not any other
[Wordnet 2006]
rather than the weak sense of merely looking the same, as in "identical
houses". These are common, ordinary words, and no more need specialist
definitions in the Python documentation than do the other common,
ordinary words used, such as "never", "changes" or "created".
An object's identity is that quality which distinguishes it from every
other object. The nature of that quality is not important. Not
withstanding such interesting but irrelevant philosophical questions as
the Paradox Of My Grandfather's Axe, the intuitive, common, plain-English
meaning of identity is all we need to understand object identity, because
it's the same meaning.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-15 10:11 -0700 |
| Message-ID | <mailman.7009.1392484350.18130.python-list@python.org> |
| In reply to | #66454 |
On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa <marko@pacujo.net> wrote: > Steven D'Aprano <steve+comp.lang.python@pearwood.info>: >> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote: >>> Steven D'Aprano <steve+comp.lang.python@pearwood.info>: >>>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote: >>>>> 5. id(x) == id(y) iff x is y >>>> >>>> # Counter-example >>>> py> x = 230000 >>>> py> idx = id(x) >>>> py> del x >>>> py> y = 420000 >>>> py> idy = id(y) >>>> py> idx == idy >>>> True >>> >>> I don't accept that as a counterexample. > >> Why? > > Nowhere do I see the violating "x is y". You formulated your rule as a rule of inference. The logical inference from the above is that x is y, which is false even if it can't be directly tested in Python. >> All I need to do is show a case where two distinct objects have the >> same ID. > > How do you know objects are "distinct"? Myself, I would use the "is" > test. Eliding over details of how one knows that both of the literals above create objects, if the objects are separately created, then they are distinct objects. >>> That's the point. I don't think id() and "is" have any abstract >>> meaning on top of the formal axioms. >> >> Who is talking about "abstract meaning"? > > I am. I mean, "implementation-independent". > >> Object identity is simple and well-defined in Python. I don't know why >> you are so resistant to this. Read the documentation. > > It is not defined at all: > > 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. > > Thus "x and y are identical" *means* "x is y" and nothing else. This notion of identity sounds useless, and if that is the way you prefer to understand it then you can safely ignore that it exists. I think that most users though inherently understand the concept of objects being distinct or identical and see the value in being able to test for this.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 22:20 +0200 |
| Message-ID | <87mwhsku0e.fsf@elektro.pacujo.net> |
| In reply to | #66457 |
Ian Kelly <ian.g.kelly@gmail.com>: > On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa <marko@pacujo.net> wrote: >> Thus "x and y are identical" *means* "x is y" and nothing else. > > This notion of identity sounds useless, and if that is the way you > prefer to understand it then you can safely ignore that it exists. I > think that most users though inherently understand the concept of > objects being distinct or identical and see the value in being able to > test for this. It is not useless to identify your fundamental definitions and axioms instead of resorting to circular reasoning. The original question was how a beginning programmer could "get" lists. We very quickly descended into the murky waters of "objects" of an underlying machine and CPython's way of implementing things. I was wondering if there was a way to "get" integers, lists, references etc without hauling the poor student under the keel. In a word, could Python be your first programming language? Marko
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-15 14:20 -0700 |
| Message-ID | <mailman.7023.1392499250.18130.python-list@python.org> |
| In reply to | #66479 |
On Sat, Feb 15, 2014 at 1:20 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > Ian Kelly <ian.g.kelly@gmail.com>: > >> On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa <marko@pacujo.net> wrote: >>> Thus "x and y are identical" *means* "x is y" and nothing else. >> >> This notion of identity sounds useless, and if that is the way you >> prefer to understand it then you can safely ignore that it exists. I >> think that most users though inherently understand the concept of >> objects being distinct or identical and see the value in being able to >> test for this. > > It is not useless to identify your fundamental definitions and axioms > instead of resorting to circular reasoning. > > The original question was how a beginning programmer could "get" lists. > We very quickly descended into the murky waters of "objects" of an > underlying machine and CPython's way of implementing things. I was > wondering if there was a way to "get" integers, lists, references etc > without hauling the poor student under the keel. > > In a word, could Python be your first programming language? Absolutely, many people learn Python as their first language. Even MIT famously uses it for their introductory computer science class. And I think that most of them do it without getting into internal details like memory addresses and the heap.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-15 09:47 -0800 |
| Message-ID | <26997873-8f75-4df7-8f08-565d89d1d10f@googlegroups.com> |
| In reply to | #66454 |
On Saturday, February 15, 2014 9:59:59 PM UTC+5:30, Marko Rauhamaa wrote: > Steven D'Aprano: > > Object identity is simple and well-defined in Python. I don't know why > > you are so resistant to this. Read the documentation. > It is not defined at all: In a certain way thats what I am saying. But you are saying it stronger than I would... See below > 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. > Thus "x and y are identical" *means* "x is y" and nothing else. Formally yes. But in practice, we (where we means experienced programmers and presumably excludes persons like the OP) understand identity 'somehow-or-other' What does that 'somehow-or-other' consist of? I would argue that we do that comprehending-act by translating to a kind of C. Maybe an informal, pidgin C but close enough that we get (something of) the semantics.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 19:17 +0000 |
| Message-ID | <52ffbd39$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66454 |
On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote: > Steven D'Aprano <steve+comp.lang.python@pearwood.info>: >> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote: >>> Steven D'Aprano <steve+comp.lang.python@pearwood.info>: >>>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote: >>>>> 5. id(x) == id(y) iff x is y >>>> >>>> # Counter-example >>>> py> x = 230000 >>>> py> idx = id(x) >>>> py> del x >>>> py> y = 420000 >>>> py> idy = id(y) >>>> py> idx == idy >>>> True >>> >>> I don't accept that as a counterexample. > >> Why? > > Nowhere do I see the violating "x is y". Do you truly think that there is even the tiniest, most microscopic chance that the int 230000 which has been garbage-collected and no longer exists, and the int 420000, are the same object? >> All I need to do is show a case where two distinct objects have the >> same ID. > > How do you know objects are "distinct"? Myself, I would use the "is" > test. I know objects are distinct if they are objects with different values, such as 230000 and 420000, due to the fundamental fact that ints cannot have the value 230000 and 420000 at the same time. I leverage my knowledge that ints are intended to model the mathematical integers, and while that model is not perfect, it is not so bad as to have 230000 and 420000 be the same number. I also know that objects are distinct if one of them has been garbage collected, on the account of it no longer existing. >>> That's the point. I don't think id() and "is" have any abstract >>> meaning on top of the formal axioms. >> >> Who is talking about "abstract meaning"? > > I am. I mean, "implementation-independent". "Abstract meaning" does not mean "implementation independent". The definition of identity given in the documentation is both implementation independent and concrete: identity is tied concretely to the creation of the object, while still leaving implementations free to choose exactly how they tie identity to creation. >> Object identity is simple and well-defined in Python. I don't know why >> you are so resistant to this. Read the documentation. > > It is not defined at all: > > 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. > > Thus "x and y are identical" *means* "x is y" and nothing else. You are correct, "x and y are identical" does mean that "x is y". That is exactly the point. However, the `is` operator is not necessarily the same as the English word "is". Is some languages, the `is` operator is a synonym for the equals operator. That is not the case in Python. In Python, the *expression* `x is y` has the same meaning as the English sentence "x is y" in the strong sense of testing identity, rather than the weak sense of merely testing similarities (or metaphor). So the Python docs don't merely give a circular definition, they distinguish between two different and competing possibilities: (1) The `is` operator means the same as the == operator. (NO) (2) The `is` operator tests for object identity. (YES) Please also see my response to Roy Smith's message. Every object has a unique (during the lifetime of the object) identity. The specific nature of that identity is implementation-dependent, and strictly irrelevant. The `is` operator tests whether the two operands are the same object, that is, whether they have the same identity. That's all it does. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 23:01 +0200 |
| Message-ID | <87fvnkks3i.fsf@elektro.pacujo.net> |
| In reply to | #66476 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote: >> Nowhere do I see the violating "x is y". > > Do you truly think that there is even the tiniest, most microscopic > chance that the int 230000 which has been garbage-collected and no > longer exists, and the int 420000, are the same object? What were we talking about again? Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-16 02:25 +0000 |
| Message-ID | <530021b1$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66482 |
On Sat, 15 Feb 2014 23:01:53 +0200, Marko Rauhamaa wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:
>>> Nowhere do I see the violating "x is y".
>>
>> Do you truly think that there is even the tiniest, most microscopic
>> chance that the int 230000 which has been garbage-collected and no
>> longer exists, and the int 420000, are the same object?
>
> What were we talking about again?
Two distinct objects with the same id(). I demonstrated a situation where
your claim:
id(x) == id(y) implies x is y
fails. I explained *twice* how to rescue your claim. In each case you
deleted my explanation, apparently unread. I can only conclude that you
are not actually engaging in this discussion in good faith.
For anyone else reading, id(x) == id(y) implies that x is y only if x and
y exist at the same time, in the same process. Python can re-use IDs, and
you cannot compare IDs from multiple processes.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-16 13:18 +0200 |
| Message-ID | <87sirjgvac.fsf@elektro.pacujo.net> |
| In reply to | #66499 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> On Sat, 15 Feb 2014 23:01:53 +0200, Marko Rauhamaa wrote:
> I demonstrated a situation where your claim:
>
> id(x) == id(y) implies x is y
>
> fails.
My from-the-hip formulation can obviously be inaccurate, but I was
hoping the point was clear.
The Python language specification feels the need to introduce the
nebulous concept of "object lifetime." I believe that concept can be
more confusing than useful. Compare that with Common Lisp, whose objects
are by definition eternal; there's no garbage collection. Practical
implementations do collect garbage, but that's an optimization that
doesn't affect the observed output of a program.
It is possible to define id() without making any references to the
object lifetime.
Let's, then, make a more satisfactory attempt at specifying id():
1. For any argument, the function
id
returns an integer.
2. For any pair of arguments, the function
lambda x, y: (id(x) == id(y)) == (x is y)
returns True.
That should cover all valid implementations and uses of id().
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 22:31 +1100 |
| Message-ID | <mailman.6984.1392463886.18130.python-list@python.org> |
| In reply to | #66402 |
On Sat, Feb 15, 2014 at 9:13 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > A new attempt: Sorry, hadn't seen this when I posted. > 0. x is x This is the definition of identity. > 1. if x is y then y ix x Yes, because if x is y, there is absolutely no difference between using one of those names or the other, in any context. > 2. if x is y and y is z then x is z Extension of the above. The first statement proves that you can substitute 'x' for 'y' in the second without changing its truthiness; therefore, based on the definition of identity, 'x is z' must be identical to 'y is z'. > 3. after x = y, x is y This is the definition of assignment. (Obviously this axiom depends on x and y being simple names and nothing tampering with the situation in any way. But yes, this is exactly what assignment is.) > 4. if x is y and x == x, then x == y Yes. As in case 2, 'x is y' implies that you can substitute 'x' for 'y' or vice versa. Therefore, if x == x, then y == y, and x == y, and y == x; because in each case, what you're doing is "object #1423443, are you equal to object #1423443 or not?", regardless of the name you use to access that object. > 5. id(x) == id(y) iff x is y This is the definition of id(). Note that it does depend on something holding a reference to each of x and y; if it's possible for the objects' lifetimes to not overlap, it's possible for them to reuse ids: >>> [1,2,3] is [2,3,4] False >>> id([1,2,3]) == id([2,3,4]) True But if x and y are simple names (and therefore retaining their referent objects), then your statement is valid. > Does that cover it? Largely axiomatically, yes. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web