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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-14 20:24 -0800 |
| Message-ID | <cf89a78f-3d3a-4df5-9a9a-c0bda8359d8b@googlegroups.com> |
| In reply to | #66356 |
On Saturday, February 15, 2014 9:03:36 AM UTC+5:30, Chris Angelico wrote: > On Sat, Feb 15, 2014 at 2:14 PM, Rustom Mody wrote: > > On Saturday, February 15, 2014 8:12:14 AM UTC+5:30, Chris Angelico wrote: > >> Well, for a start, I'd use Python 3, so there's no need to explain why > >> some numbers have an L after them :) > > Nice point! > > And only sharpens what I am saying -- python 3 is probably more confusing than > > 2 wrt object identity > How so? Py3 eliminates an unnecessary difference: > >>> 1L == 1 > True > >>> 1L is 1 > False > In Py3, this can't happen, because there simply is no distinction. > (That said, the Py3 unification does mean that small integers pay the > performance cost of long integers. I've mentioned before that it may > be worth having an "under the covers" optimization whereby small > integers are stored in a machine word - but this should be utterly > invisible to the user. As far as the programmer's concerned, an int is > an int is an int.) > >> When it's utterly impossible for it to matter in any way, Python is > >> allowed to reuse objects. > >> I think that's simple enough to explain. There's nothing you can do to > >> distinguish one 6 from another, so Python's allowed to have them the > >> same. > > Simple?? > >>>> x=1234 > >>>> y=1234 > >>>> x is y > > False > >>>> 1234 is 1234 > > True > >>>> x=123 > >>>> y=123 > >>>> x is y > > True > In all three cases, Python is allowed to use separate objects. Nothing > forces them to be shared. But in all three cases, there's no way you > could distinguish one from another, so Python's allowed to reuse the > same object. > > "utterly impossible to matter"... > > "nothing you can do to distinguish one 6 from another" > > All depend on doing one of these 3 for dealing with object identity > > 1. Circular definition > > 2. Delve into implementation > > 3. Wildly wave the hands > How do you distinguish between any other identical things? Once you've > decided that they're equal, somehow you need to separate identity from > value. Implicit circularity problem continues... See below > I could have three six-sided dice, all made from the same > mould, and yet each one is a separate object. If I hold all three in > my hand and toss them onto the table, can I recognize which one is > which? No, they're identical. Are they distinct objects? Yes. In the case of physical objects like dice there is a fairly unquestionable framing that makes identity straightforward -- 4-dimensional space-time coordiantes. If the space-time coordinates of 2 objects are all equal then the objects are identical, else not. Now we analogize the space-time identity of physical objects to computer identity of computer objects (so-called) and all sorts of problems ensue. To start with we say two objects are identical if they have the same memory address. Then what happens to the same memory address on different computers? If you say nothing on two different computers are identical then how do you define the correctness of a serialization protocol? And is 'different computer' even well-defined? Think of clusters, COWs NOWs, and other beasties ending in the cloud... IOW when we analogize 4-dim infinite space-time into the confines of 'a computer' weve bought bigger problems than we disposed off, because - for space-time it is unreasonable to imagine a larger frame into which that is embedded - for computers that larger frame is a key part -- starting with the fact that you and I are having a conversation right now tl;dr Analogizing physical objects to computer 'objects' is a mistake
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 15:37 +1100 |
| Message-ID | <mailman.6958.1392439042.18130.python-list@python.org> |
| In reply to | #66361 |
On Sat, Feb 15, 2014 at 3:24 PM, Rustom Mody <rustompmody@gmail.com> wrote: >> I could have three six-sided dice, all made from the same >> mould, and yet each one is a separate object. If I hold all three in >> my hand and toss them onto the table, can I recognize which one is >> which? No, they're identical. Are they distinct objects? Yes. > > In the case of physical objects like dice there is a fairly > unquestionable framing that makes identity straightforward -- > 4-dimensional space-time coordiantes. If the space-time coordinates of > 2 objects are all equal then the objects are identical, else not. Not once you roll them, which is why I specifically used dice. This exact situation comes up in roleplaying games - suppose you want to get a random number from 0 to 999 (or 1 to 1000, by declaring that a result of 0 is interpreted as 1000). The most common way to do this is to roll 10-sided dice for the digits; you can either roll one d10 three times, or three dice all at once. In the latter case, you somehow need to pre-declare which one is the hundreds digit, which is the tens, and which is the units, which means you need some way to distinguish the three dice after you roll them (as you can't recognize by position). This is why dice exist in a variety of colors [1]. Indistinguishable yet distinct dice... and it's actually possible to merge all three into a single object (which is what happens when you roll one three times instead of rolling three once), just as Python is allowed to do. By the way, if you get into quantum physics, you can't depend on three dimensions of space and one of time to distinguish objects. You also need spin. And I think you also need insanity, because you'll be given it on arrival if you don't have enough. ChrisA [1] Well, that and to look cool. I don't know that any system other than FATAL requires you to roll d1,000,000 on six dice, so three colors would normally be sufficient. But it's fun to have the full spectrum.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 06:54 +0000 |
| Message-ID | <52ff0f3f$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66365 |
On Sat, 15 Feb 2014 15:37:20 +1100, Chris Angelico wrote:
[...]
> This is why dice exist in a variety of colors [1]. Indistinguishable yet
> distinct dice...
Since they have different colours, they can be distinguished and aren't
indistinguishable.
One might also distinguish three dice by position in space ("the die
closest to the wall counts as the HUNDREDS digit, the one closest to me
counts as the TENS digit, and the one closest to you counts as the UNITS
digit") or by space ("roll this die first for the HUNDREDS, then roll
that one for TENS, then this third one for UNITS"). Or scent, or texture,
or the typeface used for the numbers.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 18:19 +1100 |
| Message-ID | <mailman.6972.1392448757.18130.python-list@python.org> |
| In reply to | #66385 |
On Sat, Feb 15, 2014 at 5:54 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 15 Feb 2014 15:37:20 +1100, Chris Angelico wrote:
>
> [...]
>> This is why dice exist in a variety of colors [1]. Indistinguishable yet
>> distinct dice...
>
> Since they have different colours, they can be distinguished and aren't
> indistinguishable.
Sorry, what I meant was that different colors are available for
purchase, as a means of avoiding this problem. If you buy a dozen dice
in mixed colors, you can simply declare "the red one is the hundreds,
the blue one is tens, the green one is units", which is the most
common solution to this exact issue of dice being indistinguishable
yet distinct.
> One might also distinguish three dice by position in space ("the die
> closest to the wall counts as the HUNDREDS digit, the one closest to me
> counts as the TENS digit, and the one closest to you counts as the UNITS
> digit")
Yes, but prior to rolling, you can't necessarily know what's going to
be easy to determine. Rolling dice tends to randomize their positions
somewhat, and it's impractical to get out the tape measure to
determine which one is closest to the wall :)
> or by space ("roll this die first for the HUNDREDS, then roll
> that one for TENS, then this third one for UNITS").
Distinguishing by time is the other common method that I mentioned. In
that case, there's really no reason to distinguish them at all, so you
can use the same object three times - like using the string "foobar"
three times and perhaps finding that it's the same object.
> Or scent, or texture, or the typeface used for the numbers.
Then they're not indistinguishable :)
Having grown up in a business that sells dice (though, oddly enough,
not for RPGs - I learned that d12s are popular for practicing
multiplication tables, not that they're used for a barbarian's hit
points and great-axe damage), I know how many identical dice you can
get hold of. We had trays and trays of them at one point... then
migrated to bulk bags. Though we usually tried to split them up, 50
dice per bag, so we could keep some track of inventory. And we were
retailing, and dice weren't a huge part of our business. There are
plenty of ways for dice to differ, but that's like having 5, 5.0, 5L
(if Py2), and (5+0j), all of which are five, but all of which are
distinct and must be kept separate.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-14 22:20 -0700 |
| Message-ID | <mailman.6962.1392441685.18130.python-list@python.org> |
| In reply to | #66361 |
On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody <rustompmody@gmail.com> 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.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 07:03 +0000 |
| Message-ID | <52ff1134$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66369 |
On Fri, 14 Feb 2014 22:20:35 -0700, Ian Kelly wrote: > On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody <rustompmody@gmail.com> > 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. Correct. CPython does not move objects around in memory during their lifespan, so CPython can reuse the memory address as the ID. Jython and IronPython do move objects around, so they cannot use memory addresses as IDs. Instead they number each object sequentially. PyPy is even more complicated. Objects, like particles in quantum mechanics, can appear and disappear from existence between observations as the optimizing compiler does its work. For example, a list of Python float objects may be transparently converted into an array of machine doubles, then turned back into a Python object when you try to access it again. The PyPy compiler has to take great care to ensure that the list (and the floats!) get the same IDs before and after, since that is defined behaviour in the language spec. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 16:31 +1100 |
| Message-ID | <mailman.6964.1392442298.18130.python-list@python.org> |
| In reply to | #66361 |
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, simply because it's not possible for it to be otherwise. However, the converse isn't necessarily true; two objects may have the same identity while being at different addresses (or, more likely, one object may occupy different memory addresses over time, if the gc moves it around). But since memory addresses are completely inaccessible to Python code, we can't say whether two objects have the same address. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-14 22:07 -0800 |
| Message-ID | <dfe26f72-10bc-466d-8086-2a0e32880aae@googlegroups.com> |
| In reply to | #66371 |
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 On Saturday, February 15, 2014 11:01:35 AM UTC+5:30, Chris Angelico wrote: > On Sat, Feb 15, 2014 at 4:20 PM, Ian Kelly wrote: > > On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody 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, simply because it's not > possible for it to be otherwise. However, the converse isn't > necessarily true; two objects may have the same identity while being > at different addresses (or, more likely, one object may occupy > different memory addresses over time, if the gc moves it around). But > since memory addresses are completely inaccessible to Python code, we > can't say whether two objects have the same address. Nice point! I earlier talked of the macro problems of identity, viz across machines. You are bringing up a more 'micro' angle, viz gc. An even more micro (or lower level) example would be the mismatch between physical and virtual memory, dram and cache etc etc. Is memory such a clear concept? Just different examples to show that object identity is anything but straightforward
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-15 17:19 +1100 |
| Message-ID | <mailman.6968.1392445192.18130.python-list@python.org> |
| In reply to | #66374 |
Rustom Mody <rustompmody@gmail.com> writes: > Then you are obliged to provide some other way of understanding > object-identity How about: Every object has an identity, which is unique among all concurrently-existing objects. The ‘is’ operator queries whether two references are referring to objects with the same identity, which implies they are actually referring to the same object. Is that sufficient? > I earlier talked of the macro problems of identity, viz across > machines. Python doesn't make any promises about object identity beyond the current run-time of a single instance of a program. So while the problem you describe is interesting, it isn't relevant when talking about Python object identity. -- \ “When in doubt tell the truth. It will confound your enemies | `\ and astound your friends.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-14 22:31 -0800 |
| Message-ID | <464e5b36-914d-42c2-8d71-7189f36544c8@googlegroups.com> |
| In reply to | #66379 |
On Saturday, February 15, 2014 11:49:38 AM UTC+5:30, Ben Finney wrote: > Rustom Mody writes: > > Then you are obliged to provide some other way of understanding > > object-identity > How about: Every object has an identity, which is unique among all > concurrently-existing objects. The 'is' operator queries whether two > references are referring to objects with the same identity, which > implies they are actually referring to the same object. > Is that sufficient? Are you explaining or defining identity? As an explanation its ok though a bit tautologous As a definition its circular [Just for context remember the OP -- a noob father-son duo confused by python's memory model] > > I earlier talked of the macro problems of identity, viz across > > machines. > Python doesn't make any promises about object identity beyond the > current run-time of a single instance of a program. So while the problem > you describe is interesting, it isn't relevant when talking about Python > object identity. Hard as a nail the problem persists -- Non-promise of identity implies we understand it!! > -- > \ "When in doubt tell the truth. It will confound your enemies | > `\ and astound your friends." --Mark Twain, _Following the Equator_ | > _o__) | > Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 17:23 +1100 |
| Message-ID | <mailman.6969.1392445435.18130.python-list@python.org> |
| In reply to | #66374 |
On Sat, Feb 15, 2014 at 5:07 PM, Rustom Mody <rustompmody@gmail.com> wrote: > Nice point! > I earlier talked of the macro problems of identity, viz across machines. > You are bringing up a more 'micro' angle, viz gc. > An even more micro (or lower level) example would be the mismatch between > physical and virtual memory, dram and cache etc etc. > Is memory such a clear concept? > > Just different examples to show that object identity is anything but > straightforward Not really; they just show that object identity is nothing to do with memory location. An object is itself, and is not anything else, and neither of those truisms has anything to do with memory. I could implement Python using a pencil and paper, using physical pieces of string to create references; if a gust of wind blows all the paper around, it won't change anything. (Though it might be a problem if I have any weak references...) You could walk up to me and look at my pieces of paper, and you'll know if two strings are linking to the same paper; it's obvious that that paper is the same thing as itself. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-15 01:08 -0700 |
| Message-ID | <mailman.6975.1392451731.18130.python-list@python.org> |
| In reply to | #66374 |
On Fri, Feb 14, 2014 at 11:07 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Saturday, February 15, 2014 10:50:35 AM UTC+5:30, Ian wrote:
>> 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
I thought that I did. Repeating myself from what you quoted above:
If two objects share the same creation, then they're the same object.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-02-15 12:42 +0000 |
| Message-ID | <mailman.6991.1392468186.18130.python-list@python.org> |
| In reply to | #66374 |
On 15/02/2014 06:07, Rustom Mody wrote: > Then you are obliged to provide some other way of understanding object-identity I have no interest in understanding object identity, I can write code quite happily without it. If you (plural) are interested in understanding this subject I hope you enjoy comparing the various Python implementations while I'm *STILL* writing code. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 15:44 +0200 |
| Message-ID | <878utcmqwo.fsf@elektro.pacujo.net> |
| In reply to | #66429 |
Mark Lawrence <breamoreboy@yahoo.co.uk>:
> I have no interest in understanding object identity, I can write code
> quite happily without it.
Luckily, what we are now debating is mostly terminology and points of
view where the outcomes are unaffected.
However, as an example, it is important to know if you should write:
if x is not None:
...
or if
if x != None:
...
is more robust.
As an aside, thousands upon thousands of Java programmers churn out code
quite happily with no interest in understanding the "happens before"
relation (<URL:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5>),
which is heavily leaned on by Hotspot's JIT optimizer. I find that
disconcerting.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-16 06:00 -0800 |
| Message-ID | <8ca61d1a-b4f6-4677-9cd6-ba15c251f173@googlegroups.com> |
| In reply to | #66435 |
On Saturday, February 15, 2014 7:14:39 PM UTC+5:30, Marko Rauhamaa wrote: > Mark Lawrence: > > I have no interest in understanding object identity, I can write code > > quite happily without it. > Luckily, what we are now debating is mostly terminology and points of > view where the outcomes are unaffected. > However, as an example, it is important to know if you should write: > if x is not None: > ... > or if > if x != None: > ... > is more robust. Yes This is my main beef: Not that both are possible but that the first is *recommended* and the second not. Something like a C compiler manual advising: You can write x*8 but its better to drop out into asm and write shl $3, %eax
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2014-02-16 11:29 -0500 |
| Message-ID | <mailman.7065.1392568208.18130.python-list@python.org> |
| In reply to | #66536 |
On 2/16/14 9:00 AM, Rustom Mody wrote: > On Saturday, February 15, 2014 7:14:39 PM UTC+5:30, Marko Rauhamaa wrote: >> Mark Lawrence: > >>> I have no interest in understanding object identity, I can write code >>> quite happily without it. > >> Luckily, what we are now debating is mostly terminology and points of >> view where the outcomes are unaffected. > >> However, as an example, it is important to know if you should write: > >> if x is not None: >> ... > >> or if > >> if x != None: >> ... > >> is more robust. > > Yes This is my main beef: > Not that both are possible but that the first is *recommended* and the second not. > I'm not sure why you don't like the recommendation, or if you just want people to be more explicit about why it is recommended. My main reason for preferring "x is not None" is that if x's class defines __ne__ incorrectly, "x != None" can come out wrong. And yes, I have actually debugged problems where that was the root cause. If you use "x is not None", nothing about x's class can interfere with the correct operation. > Something like a C compiler manual advising: > You can write x*8 but its better to drop out into asm and write > shl $3, %eax > -- Ned Batchelder, http://nedbatchelder.com
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-16 08:50 -0800 |
| Message-ID | <d9b3d8e9-9483-4255-bdd9-c7fed1a62d5d@googlegroups.com> |
| In reply to | #66554 |
On Sunday, February 16, 2014 9:59:53 PM UTC+5:30, Ned Batchelder wrote: > On 2/16/14 9:00 AM, Rustom Mody wrote: > > On Saturday, February 15, 2014 7:14:39 PM UTC+5:30, Marko Rauhamaa wrote: > >> Mark Lawrence: > >>> I have no interest in understanding object identity, I can write code > >>> quite happily without it. > >> Luckily, what we are now debating is mostly terminology and points of > >> view where the outcomes are unaffected. > >> However, as an example, it is important to know if you should write: > >> if x is not None: > >> ... > >> or if > >> if x != None: > >> ... > >> is more robust. > > Yes This is my main beef: > > Not that both are possible but that the first is *recommended* and the second not. > I'm not sure why you don't like the recommendation, or if you just want > people to be more explicit about why it is recommended. My main reason > for preferring "x is not None" is that if x's class defines __ne__ > incorrectly, "x != None" can come out wrong. And yes, I have actually > debugged problems where that was the root cause. > If you use "x is not None", nothing about x's class can interfere with > the correct operation. Ok But for that Ive to use is And as a teacher Ive to explain is Might as well use C and get on with pointers To me 'is' is a can of worms Mostly I dont need to open that can In the few instances when I need to open it, I am allowed (I hope!) to say "Ugh!"
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-16 20:01 +0200 |
| Message-ID | <87eh33gcmt.fsf@elektro.pacujo.net> |
| In reply to | #66556 |
Rustom Mody <rustompmody@gmail.com>:
> But for that Ive to use is
> And as a teacher Ive to explain is
> Might as well use C and get on with pointers
>
> To me 'is' is a can of worms
I'm not against "is," but it must be carefully defined and taught.
As far as "x is None" is concerned, a key piece of information is
presented on <URL: http://docs.python.org/3.2/library/constants.html>:
None
The sole value of the type NoneType.
Unfortunately the page is a bit confusing. It says:
A small number of constants live in the built-in namespace.
So an essential characteristic of the None object (uniqueness) is
mentioned in the middle of the discussion on the built-in namespace. The
index doesn't contain an entry on NoneType.
Thus, there might still be a nagging concern that a second NoneType
object x such that
x == None and x is not None
could crop up (from native code, perhaps).
Marko
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-02-16 18:36 +0000 |
| Message-ID | <mailman.7069.1392575819.18130.python-list@python.org> |
| In reply to | #66560 |
On 16/02/2014 18:01, Marko Rauhamaa wrote: > Rustom Mody <rustompmody@gmail.com>: > >> But for that Ive to use is >> And as a teacher Ive to explain is >> Might as well use C and get on with pointers >> >> To me 'is' is a can of worms > > I'm not against "is," but it must be carefully defined and taught. > > As far as "x is None" is concerned, a key piece of information is > presented on <URL: http://docs.python.org/3.2/library/constants.html>: > > None > The sole value of the type NoneType. > > Unfortunately the page is a bit confusing. It says: > > A small number of constants live in the built-in namespace. > > So an essential characteristic of the None object (uniqueness) is > mentioned in the middle of the discussion on the built-in namespace. The > index doesn't contain an entry on NoneType. > > Thus, there might still be a nagging concern that a second NoneType > object x such that > > x == None and x is not None > > could crop up (from native code, perhaps). > > > Marko > Patches are always welcome :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-17 05:52 +0000 |
| Message-ID | <5301a395$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66560 |
On Sun, 16 Feb 2014 20:01:46 +0200, Marko Rauhamaa wrote:
> As far as "x is None" is concerned, a key piece of information is
> presented on <URL: http://docs.python.org/3.2/library/constants.html>:
>
> None
> The sole value of the type NoneType.
^^^^
Sole, adj. "being the only one; single and isolated from others", e.g.
"the sole heir", "the sole example".
In plain English, None is the sole (only, single) instance of its type.
In computer science jargon, None is a singleton.
> Thus, there might still be a nagging concern that a second NoneType
> object x such that
>
> x == None and x is not None
>
> could crop up (from native code, perhaps).
If that were possible, then None would not be the sole instance of its
type. Since None is documented as being a singleton, that would be a bad
bug.
--
Steven
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web