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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-02-15 15:40 -0500 |
| Message-ID | <mailman.7021.1392496901.18130.python-list@python.org> |
| In reply to | #66374 |
On 2/15/2014 1:07 AM, Rustom Mody wrote: > On Saturday, February 15, 2014 10:50:35 AM UTC+5:30, Ian wrote: >> On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody wrote: >>> 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. > >> This is false. It happens to hold for CPython, but that's an >> implementation detail. The definition of object identity does not >> depend on memory address. It also doesn't have anything to do with >> space-time coordinates. The concept of object identity is an >> abstraction, not an analogy from physics. > >> The language reference states, "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." >> Okay, so that quote does bring up memory address, but in my >> interpretation that's just an analogy to introduce the concept. The >> more important part of that sentence is the first part, which ties an >> object's identity to its creation. If two objects share the same >> creation, then they're the same object. > > Whats the notion of object identity is the question. > Ok so you reject the memory addr as an 'implementation detail' > Then you are obliged to provide some other way of understanding object-identity 'Identity' is an abstraction. For immutable objects, it is essentially irrelevant. For mutable objects, it is essential in the following sense. A and B are the same object if mutating A necessarily mutates B and different if they can be independently mutated. The id() of an object is a fixed integer that is temporally unique. An implementation might use the id to access objects. When one executes Python mentally, one might skip implementing id(). Its main use is to test an implementation. Most beginners should ignore it. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-16 02:27 +0000 |
| Message-ID | <5300221c$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66480 |
On Sat, 15 Feb 2014 15:40:54 -0500, Terry Reedy wrote: > 'Identity' is an abstraction. For immutable objects, it is essentially > irrelevant. For mutable objects, it is essential in the following sense. > A and B are the same object if mutating A necessarily mutates B and > different if they can be independently mutated. That's not quite right. See the earlier example in this thread about numpy arrays. Since mutator methods can have side-effects, and objects can act as proxies or views to other methods, we can't make any conclusion about identity from the fact that mutation affects two or more objects. [Aside: I think the numpy array API is poor, since it doesn't make clear the distinction between arrays which are being used as views to another array, and arrays which are being used as independent arrays.] -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2014-02-15 19:02 +0000 |
| Message-ID | <ldodkb$acl$1@reader1.panix.com> |
| In reply to | #66371 |
On 2014-02-15, Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Feb 15, 2014 at 4:20 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote: >> On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody <rustompmody@gmail.com> wrote: >>> To start with we say two objects are identical if they have the same >>> memory address. >> >> This is false. It happens to hold for CPython, but that's an >> implementation detail. The definition of object identity does not >> depend on memory address. It also doesn't have anything to do with >> space-time coordinates. The concept of object identity is an >> abstraction, not an analogy from physics. > > With the restrictions of computer memory, I suspect that two objects > with the same address must be identical, That's true if they have the same address _at_the_exact_same_time_. [AND IF the two chunks of code evaluating the addresses of the objects share a machine-level address space -- which I doubt is actually required by the Python language definition. It would be difficult (but not impossible) to implement a Python where that wasn't true.] However, it's possible for object 1 to have address XYZ at one point in time and object 2 to have address XYZ at a different point in time even though object 1 and object 2 are different objects. The tricky bit is that those two points in time may occur at adjacent "lines" when your program is executing. They may even occur at two different points within the same line of code. IOW, there's just no reason to assume that: address_of(object1) == address_of(ojbect2) is equivalent to object1 is object2 Garbage collection could kick in after the evaluation of address_of(object1) and before the evaluation of address_of(object2) with the result that the two objects would appear to have the same address in memory. So, unless you're working on the guts of a Python implementation you've got to just plain stop thinking about memory addresses. Period. -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 06:44 +0000 |
| Message-ID | <52ff0cb7$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66361 |
On Fri, 14 Feb 2014 20:24:20 -0800, Rustom Mody wrote: > 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. That simply is not correct. (1) General relativity tells us that not all observers will agree on the space-time coordinates of two objects, since not all observers agree on a single frame of reference. (2) Quantum mechanics tells us that objects are not located at a single space-time coordinate. Objects are "smeared out" over space (and time). We cannot really talk about the location of an object, but only about the probability of a measurement registering the object at a certain location. > 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. Not quite. We say that two objects are identical (that is, that they actually are the same object) if they exist simultaneously, in the same process, and have the same ID. Normally we don't bother to say that they must be in the same process, as that is implied by our understanding of how computers normally work. In fact, even the above is a simplification, since processes may share certain objects. This is why Python prohibits Ruby-style monkey-patching of built-in types. If we could add or remove methods from (say) lists, that could affect more than one Python process. But ignoring complications like that, we can say that for a wide range of implementations, the condition "two objects exist at the same time and have the same ID" is equivalent to saying that they exist at the same time with 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? I would not expect that the None object running on my computer is the same None object running on another computer. None is a singleton *within a single running process*, not over the entire universe of Python virtual machines. > And is 'different computer' even well-defined? Think of clusters, COWs > NOWs, and other beasties ending in the cloud... But for all of these things, we can create the abstraction of "a single process running at a single moment". True, observers in orbit around a black hole a thousand light-years away will disagree about that single moment, but we're not talking to them and don't care what they think. > 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 Over-philosophising abstractions without the sanity check of what happens in real life is an even bigger mistake. You may or may not choose to lie awake at night obsessing whether changing a tyre on your car makes it a different car (see the paradox of the Ax of my Grandfather), but the rest of us are too busy actually programming to care about such edge cases. They make good discussions for a philosophy class, but 99.999% of the time, the abstraction of computer objects being like physical objects is a good one. If you want to demonstrate the fact that this abstraction sometimes leaks, you don't need to concern yourself with cloud computing, shared process memory space, or any such thing. You just need to recognise that objects can contain themselves: py> L = [] py> L.append(L) py> L in L True Of course, if you are a fan of the Doctor Who television show, you won't be concerned by this. If the TARDIS can materialise inside itself, then there isn't any problem with lists containing themselves either. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 18:05 +1100 |
| Message-ID | <mailman.6971.1392447905.18130.python-list@python.org> |
| In reply to | #66383 |
On Sat, Feb 15, 2014 at 5:44 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > You just need to recognise that > objects can contain themselves: > > py> L = [] > py> L.append(L) > py> L in L > True > > > Of course, if you are a fan of the Doctor Who television show, you won't > be concerned by this. If the TARDIS can materialise inside itself, then > there isn't any problem with lists containing themselves either. They certainly can. In my MUD, every object has a location (which may be the equivalent of None); generally, a person's location is a room, and a grabbable object's location is either a room or a person, but it's possible for a room to have a location... a Dungeon Master can create a workroom, which is in his inventory, and then enter that workroom. Incidentally, the destruction of an object simply involves moving it to nowhere. Since "nowhere" doesn't keep any references to the things put there, those objects promptly cease to exist. It's just like Western society - you don't actually destroy anything, you just throw it away (out of sight, out of mind), and let the garbage collector dispose of it for you :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-02-16 00:29 +1300 |
| Message-ID | <bm91ciFha2sU1@mid.individual.net> |
| In reply to | #66383 |
Steven D'Aprano wrote: > (1) General relativity tells us that not all observers will agree on the > space-time coordinates of two objects, since not all observers agree on a > single frame of reference. But that doesn't mean they won't agree about whether objects are identical or not! The coordinates they use to describe spacetime locations may differ, but they will agree on whether or not they are equal. A Lorentz transformation can't cause a single point in spacetime to split into two, or two distinct points to merge into one. > (2) Quantum mechanics tells us that objects are not located at a single > space-time coordinate. Objects are "smeared out" over space (and time). > We cannot really talk about the location of an object, but only about the > probability of a measurement registering the object at a certain location. But that doesn't mean you can stuff two objects into the same space at the same time. What we perceive as solid objects are composed of fermions, which obey the Pauli exclusion principle. That means you can't have more than one of them in a given quantum state. While you *could* have two of them equally spread out over all of space, they would then have to be separated in some other dimension such as momentum or spin. So if you replace "space-time coordinates" with "quantum state", the original statement remains essentially true. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 06:15 +0000 |
| Message-ID | <52ff05e3$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66345 |
On Fri, 14 Feb 2014 17:55:52 -0800, Rustom Mody wrote: > My own preference: No is operator; only id when we deliberately need to > poke into the implementation. > > Of course I am in a miniscule minority I guess on that :-) If I have understood you, I think that's a poor way of looking at it. We can have an `is` operator to determine whether or not two objects are the same, without having a concept of object IDs; but you can't have a concept of object IDs without having distinct objects. `is` is more fundamental than id(). IDs are a proxy for distinct objects. If you live in a country with an ID card of some sort, then the IDs acts as an identifier for each unique individual. But countries without ID cards don't lack unique individual people. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-14 22:24 -0800 |
| Message-ID | <0da49167-a452-4910-ad4d-9b94d23ad448@googlegroups.com> |
| In reply to | #66378 |
On Saturday, February 15, 2014 11:45:00 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 14 Feb 2014 17:55:52 -0800, Rustom Mody wrote: > > My own preference: No is operator; only id when we deliberately need to > > poke into the implementation. > > Of course I am in a miniscule minority I guess on that :-) > If I have understood you, I think that's a poor way of looking at it. We > can have an `is` operator to determine whether or not two objects are the > same, without having a concept of object IDs; but you can't have a > concept of object IDs without having distinct objects. `is` is more > fundamental than id(). Pick is or id. Matters little To define either you need the notion of 'same' > IDs are a proxy for distinct objects. If you live in a country with an ID > card of some sort, then the IDs acts as an identifier for each unique > individual. But countries without ID cards don't lack unique individual > people. With humans like Chris' dice the notion of 'same' is unexceptionable [well sci-fi, teleportation etc aside :-) ] To define is or id or same you need to 1 use machine details or 2 do mathematics or 3 wave our hands -- Dont we all know that same is same? <Wild Wave> My bet is that python's id/is cannot be defined with 2 so we use a combo of 1 and 3
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-02-16 00:32 +1300 |
| Message-ID | <bm91icFha2sU2@mid.individual.net> |
| In reply to | #66378 |
Steven D'Aprano wrote: > IDs are a proxy for distinct objects. If you live in a country with an ID > card of some sort, then the IDs acts as an identifier for each unique > individual. But countries without ID cards don't lack unique individual > people. "You are Number Six." "I am not an id()! I am an individual object!" -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 22:37 +1100 |
| Message-ID | <mailman.6986.1392464263.18130.python-list@python.org> |
| In reply to | #66418 |
On Sat, Feb 15, 2014 at 10:32 PM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Steven D'Aprano wrote: >> >> IDs are a proxy for distinct objects. If you live in a country with an ID >> card of some sort, then the IDs acts as an identifier for each unique >> individual. But countries without ID cards don't lack unique individual >> people. > > > "You are Number Six." > "I am not an id()! I am an individual object!" Make it so, Number One. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 11:10 +0200 |
| Message-ID | <8738jkoi5l.fsf@elektro.pacujo.net> |
| In reply to | #66343 |
Chris Angelico <rosuav@gmail.com>: > On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa <marko@pacujo.net> wrote: >> Unfortunately neither the "everything is a reference" model nor the >> "small/big" model help you predict the value of an "is" operator in >> the ambiguous cases. > > Can you give an example of an ambiguous case? The "x is y" test may yield different outcomes in different, valid Python implementations: 4 is 4 (x,) is (x,) "hello" is "hello" Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 10:31 +0000 |
| Message-ID | <52ff41e3$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66394 |
On Sat, 15 Feb 2014 11:10:46 +0200, Marko Rauhamaa wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa <marko@pacujo.net>
>> wrote:
>>> Unfortunately neither the "everything is a reference" model nor the
>>> "small/big" model help you predict the value of an "is" operator in
>>> the ambiguous cases.
>>
>> Can you give an example of an ambiguous case?
>
> The "x is y" test may yield different outcomes in different, valid
> Python implementations:
>
> 4 is 4
> (x,) is (x,)
> "hello" is "hello"
But none of those examples are ambiguous. They're merely unspecified by
the language definition. Any specific implementation of Python will
return either True or False; it may be predictable, or it might be
impossible to predict until runtime, but either way we know that every
non-broken Python virtual machine must either treat the two operands as
the same object or different objects.
These are ambiguous sentences:
I saw the man with the binoculars.
Police help assault victim.
Once there was a blind carpenter who picked up his hammer and saw.
Look at that cat with one eye.
"A Python implementation can choose whether or not to re-use immutable
objects" is not ambiguous. It's just a choice.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2014-02-15 10:44 +0100 |
| Message-ID | <ldncu7$ujb$1@dont-email.me> |
| In reply to | #66343 |
Am 15.02.14 01:57, schrieb Chris Angelico: > Can you give an example of an ambiguous case? Fundamentally, the 'is' > operator tells you whether its two operands are exactly the same > object, nothing more and nothing less, so I assume your "ambiguous > cases" are ones where it's possible for two things to be either the > same object or two indistinguishable ones. What about the thing I posted down in this thread? >>> import numpy as np >>> a=np.array([1, 2, 3, 4]) >>> b=a[:] >>> id(a) 140267900969344 >>> id(b) 140267901045920 So, a and b are different things, right? >>> b[1]=37 >>> b array([ 1, 37, 3, 4]) >>> a array([ 1, 37, 3, 4]) Still they are connected. I can imagin that id() is just a debugging tool for extensions. What useful applications does it have outside of this? Christian
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 12:10 +0200 |
| Message-ID | <87r474n0ud.fsf@elektro.pacujo.net> |
| In reply to | #66399 |
Christian Gollwitzer <auriocus@gmx.de>: > Still they are connected. I can imagin that id() is just a debugging > tool for extensions. What useful applications does it have outside of > this? Calculating hash keys quickly. Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 10:53 +0000 |
| Message-ID | <52ff473b$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66399 |
On Sat, 15 Feb 2014 10:44:39 +0100, Christian Gollwitzer wrote: > Am 15.02.14 01:57, schrieb Chris Angelico: >> Can you give an example of an ambiguous case? Fundamentally, the 'is' >> operator tells you whether its two operands are exactly the same >> object, nothing more and nothing less, so I assume your "ambiguous >> cases" are ones where it's possible for two things to be either the >> same object or two indistinguishable ones. > > What about the thing I posted down in this thread? > > >>> import numpy as np > >>> a=np.array([1, 2, 3, 4]) > >>> b=a[:] > >>> id(a) > 140267900969344 > >>> id(b) > 140267901045920 > > So, a and b are different things, right? Correct. They are different objects. But they may share underlying state. > >>> b[1]=37 > >>> b > array([ 1, 37, 3, 4]) > >>> a > array([ 1, 37, 3, 4]) And indeed numpy arrays do share state. Why? No idea. Somebody thought that it was a good idea. (Not me though...) > Still they are connected. I can imagin that id() is just a debugging > tool for extensions. What useful applications does it have outside of > this? Very few. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-02-17 11:40 +1300 |
| Message-ID | <bmct3sFcb3cU1@mid.individual.net> |
| In reply to | #66408 |
Steven D'Aprano wrote: > And indeed numpy arrays do share state. Why? No idea. Somebody thought > that it was a good idea. (Not me though...) Probably because they're often large and people don't want to incur the overhead of copying them any more than necessary. So slices are defined to return views rather than independent objects. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-17 05:57 +0000 |
| Message-ID | <5301a4b9$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66567 |
On Mon, 17 Feb 2014 11:40:57 +1300, Gregory Ewing wrote: > Steven D'Aprano wrote: >> And indeed numpy arrays do share state. Why? No idea. Somebody thought >> that it was a good idea. (Not me though...) > > Probably because they're often large and people don't want to incur the > overhead of copying them any more than necessary. So slices are defined > to return views rather than independent objects. I don't have a problem with slices returning views. But they should claim to be views, not claim to be arrays: py> from numpy import array py> a = array([1, 2, 3, 4]) py> b = a[:] py> type(a) is type(b) True py> b[1] = 99 py> a array([ 1, 99, 3, 4]) You can do this to distinguish the two cases: py> a.base py> b.base is a True but I think a dedicated array_view type would have be better. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 22:21 +1100 |
| Message-ID | <mailman.6981.1392463292.18130.python-list@python.org> |
| In reply to | #66399 |
On Sat, Feb 15, 2014 at 8:44 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
>>>> import numpy as np
>>>> a=np.array([1, 2, 3, 4])
>>>> b=a[:]
>>>> id(a)
> 140267900969344
>>>> id(b)
> 140267901045920
>
> So, a and b are different things, right?
>
>>>> b[1]=37
>>>> b
> array([ 1, 37, 3, 4])
>>>> a
> array([ 1, 37, 3, 4])
>
> Still they are connected.
Well, yes, they are different things; but that doesn't mean they can't
affect each other. And you don't need numpy to see that:
>>> d = {}
>>> k1 = d.keys()
>>> k2 = d.keys()
>>> k1 is k2
False
>>> k1 == k2
True
>>> d[1]=1
>>> k1
dict_keys([1])
>>> k2
dict_keys([1])
Two separate keys views on the same dictionary will, by definition,
always show the same keys (and, I think, in the same order). But
they're still separate objects. Their identities are distinct, their
values are linked.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2014-02-16 19:16 +0000 |
| Message-ID | <h88Mu.3502$BM7.238@fx18.am4> |
| In reply to | #66399 |
On Sat, 15 Feb 2014 10:44:39 +0100, Christian Gollwitzer wrote: > Am 15.02.14 01:57, schrieb Chris Angelico: >> Can you give an example of an ambiguous case? Fundamentally, the 'is' >> operator tells you whether its two operands are exactly the same >> object, nothing more and nothing less, so I assume your "ambiguous >> cases" are ones where it's possible for two things to be either the >> same object or two indistinguishable ones. > > What about the thing I posted down in this thread? > > >>> import numpy as np a=np.array([1, 2, 3, 4]) > >>> b=a[:] > >>> id(a) > 140267900969344 > >>> id(b) > 140267901045920 > > So, a and b are different things, right? > > >>> b[1]=37 b > array([ 1, 37, 3, 4]) > >>> a > array([ 1, 37, 3, 4]) > > Still they are connected. I can imagin that id() is just a debugging > tool for extensions. What useful applications does it have outside of > this? > > Christian try id(a[0]) and id(b[0]) the two tupples are different but they both contain the same list -- If God wanted us to be brave, why did he give us legs? -- Marvin Kitman
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-15 15:20 +1100 |
| Message-ID | <mailman.6957.1392438051.18130.python-list@python.org> |
| In reply to | #66333 |
Marko Rauhamaa <marko@pacujo.net> writes: > Chris Angelico <rosuav@gmail.com>: > > Distinguishing "small values" from "big values" leads to the obvious > > question: Which is which? And why doesn't this work? > > This is related to the recent id(string) question on this forum. > > Unfortunately neither the "everything is a reference" model nor the > "small/big" model help you predict the value of an "is" operator in the > ambiguous cases. 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.) The Python implementation is free to behave unpredictably for the state of object identity. It may have some objects that conceptually may be different (i.e. you'd predict the ‘is’ operation would return False) actually be the same object (i.e. the ‘is’ operation would return True). Exactly the same case may behave differently in this regard on other Python implementations, or different versions of the same Python implementation, or even exactly the same version of the Python implementation under different circumstances. The management of object identity is an implementation detail, not to be relied on in your Python code. So, if your teaching method depends on general principles for predicting object identity, you're already losing. > Explaining Python's memory model at some level is necessary right off > the bat. However, it is far from easy to understand. The use of the term “variable”, and all the implications that has for “variables contain values” etc., is IMO too confusing, and its use in the Python documentation is not helping this. Rather, I recommend that people teaching Python should avoid the term “variable” entirely, and use the term “reference” which much more accurately implies Python's data model. An addressable item in a container is a reference, as is a name. Assignment binds a reference to a value. And so on. This article by the Effbot corrects similar misconceptions <URL:http://effbot.org/zone/python-objects.htm>, and is a valuable approach to teaching the Python data model. -- \ “Theology is the effort to explain the unknowable in terms of | `\ the not worth knowing.” —Henry L. Mencken | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web