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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | dave em <daveandem2000@gmail.com> |
|---|---|
| Date | 2014-02-14 10:08 -0800 |
| Subject | Explanation of list reference |
| Message-ID | <13208de8-0f85-4e60-b059-dc087c8fda41@googlegroups.com> |
Hello, Background: My twelve y/o son and I are still working our way through Invent Your Own Computer Games with Python, 2nd Edition. (We finished the Khan Academy Javascript Tutorials is the extent of our experience) He is asking a question I am having trouble answering which is how a variable containing a value differs from a variable containing a list or more specifically a list reference. I tried the to explain as best I can remember is that a variable is assigned to a specific memory location with a value inside of it. Therefore, the variable is kind of self contained and if you change the variable, you change the value in that specific memory location. However, when a variable contains a list reference, the memory location of the variable points to a separate memory location that stores the list. It is also possible to have multiple variable that point to the memory location of the list reference. And all of those variable can act upon the list reference. Question: Is my explanation correct? If not please set me straight :) And does anyone have an easier to digest explanation? Thanks in advance, Dave
[toc] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2014-02-14 20:26 +0200 |
| Message-ID | <qoteh35ft4q.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #66310 |
dave em writes: > He is asking a question I am having trouble answering which is how a > variable containing a value differs from a variable containing a > list or more specifically a list reference. My quite serious answer is: not at all. In particular, a list is a value. All those pointers to references to locations are implementation details. The user of the language needs to understand that an object keeps its identity when it's passed around: passed as an argument, returned by a function, stored in whatever location, retrieved from whatever location.
[toc] | [prev] | [next] | [standalone]
| From | dave em <daveandem2000@gmail.com> |
|---|---|
| Date | 2014-02-14 10:54 -0800 |
| Message-ID | <917ede6d-db7c-4a8c-8203-27677283776b@googlegroups.com> |
| In reply to | #66311 |
On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote: > dave em writes: > > > > > He is asking a question I am having trouble answering which is how a > > > variable containing a value differs from a variable containing a > > > list or more specifically a list reference. > > > > My quite serious answer is: not at all. In particular, a list is a > > value. > > > > All those pointers to references to locations are implementation > > details. The user of the language needs to understand that an object > > keeps its identity when it's passed around: passed as an argument, > > returned by a function, stored in whatever location, retrieved from > > whatever location. Jessi, Thanks for your quick response. I'm still not sure we understand. The code below illustrates the concept we are trying to understand. Case 1: Example of variable with a specific value from P 170 of IYOCGWP >>> spam = 42 >>> cheese = spam >>> spam = 100 >>> spam 100 >>> cheese 42 Case 2: Example of variable with a list reference from p 170 >>> spam = [0, 1, 2, 3, 4, 5] >>> cheese = spam >>> cheese[1] = 'Hello!' >>> spam [0, 'Hello!', 2, 3, 4, 5] >>> cheese [0, 'Hello!', 2, 3, 4, 5] What I am trying to explain is this, why in case 1 when acting on spam (changing the value from 42 to 100) only affects spam and not cheese. Meanwhile, in case two acting on cheese also affects spam. Thanks and v/r, Dave
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2014-02-14 19:20 +0000 |
| Message-ID | <ldlqab$e0g$2@dont-email.me> |
| In reply to | #66314 |
On Fri, 14 Feb 2014 10:54:29 -0800, dave em wrote: > On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote: >> dave em writes: >> >> >> >> > He is asking a question I am having trouble answering which is how a >> >> > variable containing a value differs from a variable containing a >> >> > list or more specifically a list reference. >> >> >> >> My quite serious answer is: not at all. In particular, a list is a >> >> value. >> >> >> >> All those pointers to references to locations are implementation >> >> details. The user of the language needs to understand that an object >> >> keeps its identity when it's passed around: passed as an argument, >> >> returned by a function, stored in whatever location, retrieved from >> >> whatever location. > > Jessi, > > Thanks for your quick response. I'm still not sure we understand. The > code below illustrates the concept we are trying to understand. > > Case 1: Example of variable with a specific value from P 170 of IYOCGWP > >>>> spam = 42 cheese = spam spam = 100 spam > 100 >>>> cheese > 42 > > Case 2: Example of variable with a list reference from p 170 > >>>> spam = [0, 1, 2, 3, 4, 5] >>>> cheese = spam cheese[1] = 'Hello!' spam > [0, 'Hello!', 2, 3, 4, 5] >>>> cheese > [0, 'Hello!', 2, 3, 4, 5] > > What I am trying to explain is this, why in case 1 when acting on spam > (changing the value from 42 to 100) only affects spam and not cheese. > Meanwhile, in case two acting on cheese also affects spam. A list is a container for multiple values, when you do: cheese = spam You're pointing cheese and spam at the same container. Now anything you do to the container (whether by referencing it as cheese or spam) will affect the container. If you want cheese and spam to start out as separate copies of the same list that you can manipulate independently, then you can use: cheese = [ x for x in spam ] eggs = spam[:] ham = list( spam ) >>> spam = [1,2,3,4,5] >>> cheese = [ x for x in spam ] >>> ham = list( spam ) >>> eggs = spam[:] >>> spam [1, 2, 3, 4, 5] >>> cheese [1, 2, 3, 4, 5] >>> ham [1, 2, 3, 4, 5] >>> eggs [1, 2, 3, 4, 5] >>> cheese[3] = "fred" >>> ham[4] = 'ham' >>> eggs[4] ='eggs' >>> spam [1, 2, 3, 4, 5] >>> cheese [1, 2, 3, 'fred', 5] >>> ham [1, 2, 3, 4, 'ham'] >>> eggs [1, 2, 3, 4, 'eggs'] -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-14 21:56 +0200 |
| Message-ID | <871tz5piy0.fsf@elektro.pacujo.net> |
| In reply to | #66314 |
dave em <daveandem2000@gmail.com>:
> Case 1: Example of variable with a specific value from P 170 of IYOCGWP
>
>>>> spam = 42
>>>> cheese = spam
>>>> spam = 100
>>>> spam
> 100
>>>> cheese
> 42
>
> Case 2: Example of variable with a list reference from p 170
>
>>>> spam = [0, 1, 2, 3, 4, 5]
>>>> cheese = spam
>>>> cheese[1] = 'Hello!'
>>>> spam
> [0, 'Hello!', 2, 3, 4, 5]
>>>> cheese
> [0, 'Hello!', 2, 3, 4, 5]
>
> What I am trying to explain is this, why in case 1 when acting on spam
> (changing the value from 42 to 100) only affects spam and not cheese.
> Meanwhile, in case two acting on cheese also affects spam.
A very good question! Elementary and advanced at the same time.
There are two fundamentally different kinds of values in Python: "small"
values and "big" values. A variable can only hold a small value. A list
element can only hold a small value. A dictionary entry can only hold a
small value. The same is true for an object member (aka field).
So we have four kinds of (memory) slots: variables, list elements,
dictionary entries and fields. Any slot can only hold a small value.
The small values include numbers, booleans (True or False) and
references. All other values are big, too big to fit in a slot. They
have to be stored in a "vault" big enough to hold them. This vault is
called the heap. Big values cannot be stored in slots directly; instead,
references to big values are used.
Let me now annotate your excellent example:
spam = 42 # put the small value 42 (number) in a memory slot,
# namely a variable named "spam"
cheese = spam # copy the contents of the variable "spam" into
# another memory slot, a variable named "cheese;"
# now both variables contain the same small value 42
spam = 100 # replace the contents of the variable "spam" with the
# small value 100; leave the contents of the variable
# "cheese" intact
spam
> 100 # as expected
cheese
> 42 # ditto
spam = [0, 1, 2, 3, 4, 5]
# a list is a "big" value; the statement creates a
# list of six slots in the heap an puts a number in
# each slot; then, a reference to the list is placed
# in the variable "spam"
cheese = spam # copy the reference to the six-element list from the
# variable "spam" into the variable "cheese;" the heap
# still contains only one list, and the two variables
# refer to the same one
# (rationale: big values take time and space to copy
# in full, and almost always copying references is
# good for the problem at hand; if a full copy is
# needed, Python has ways to do that, too)
cheese[1] = 'Hello!'
# a character string (text snippet) is a "big" value;
# the statement creates the six-character string
# 'Hello!' in the heap; then, a reference to the
# string is placed in the second element of the list
# referred to by the variable "cheese"
# (that's a complicated sentence with lots to chew
# even though the Python statement looks so innocently
# simple)
# there still is a single list in the heap; the list
# is still referred to by both variables; however the
# second slot of the list, which used to hold the
# number 1, has been replaced with a reference to the
# "big" string 'Hello!'
spam
> [0, 'Hello!', 2, 3, 4, 5]
# as expected, right?
cheese
> [0, 'Hello!', 2, 3, 4, 5]
# right?
The final situation is represented by this picture of Python's memory:
spam cheese
+-----+ +-----+
| . | | . |
+--+--+ +--+--+
| |
| | VARIABLES
= = =|= = = = = = =|= = = = = = = = = = = = = = = = = = =
| / THE HEAP
| ---------
| /
| |
v v
+-----+-----+-----+-----+-----+-----+
| 0 | . | 2 | 3 | 4 | 5 | a list
+-----+--+--+-----+-----+-----+-----+
|
|
|
|
v a string
+--------+
| Hello! | a string
+--------+
Marko
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-14 13:17 -0700 |
| Message-ID | <mailman.6934.1392409097.18130.python-list@python.org> |
| In reply to | #66319 |
On Fri, Feb 14, 2014 at 12:56 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > There are two fundamentally different kinds of values in Python: "small" > values and "big" values. A variable can only hold a small value. A list > element can only hold a small value. A dictionary entry can only hold a > small value. The same is true for an object member (aka field). > > So we have four kinds of (memory) slots: variables, list elements, > dictionary entries and fields. Any slot can only hold a small value. > > The small values include numbers, booleans (True or False) and > references. All other values are big, too big to fit in a slot. They > have to be stored in a "vault" big enough to hold them. This vault is > called the heap. Big values cannot be stored in slots directly; instead, > references to big values are used. This is nonsense. Python the language makes no such distinction between "big" and "small" values. *All* objects in CPython are stored internally on the heap. Other implementations may use different memory management schemes.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-14 22:58 +0200 |
| Message-ID | <87vbwho1i0.fsf@elektro.pacujo.net> |
| In reply to | #66322 |
Ian Kelly <ian.g.kelly@gmail.com>: > This is nonsense. Python the language makes no such distinction > between "big" and "small" values. *All* objects in CPython are stored > internally on the heap. Other implementations may use different memory > management schemes. You're right, of course. Conceptually, the "everything is a reference" and the "small"/"big" distinction are equivalent (produce the same outcomes). The question is, which model is easier for a beginner to grasp. Say you write: 1 + 2 You may not find it most intuitive to follow through the object instantiation and reference manipulation implicit in the "everything is a reference" model when you think you understand numbers but have little idea of memory, objects, heap, allocation etc. Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 08:16 +1100 |
| Message-ID | <mailman.6938.1392412611.18130.python-list@python.org> |
| In reply to | #66326 |
On Sat, Feb 15, 2014 at 7:58 AM, Marko Rauhamaa <marko@pacujo.net> wrote: > Say you write: > > 1 + 2 > > You may not find it most intuitive to follow through the object > instantiation and reference manipulation implicit in the "everything is > a reference" model when you think you understand numbers but have little > idea of memory, objects, heap, allocation etc. I don't object to a bit of handwaving where it doesn't matter (especially as regards language design versus language interpreter design - I'll happily talk about "storing an object on the heap" without going into the details of allocating memory, managing reference counts, and so on; the details of how CPython goes about storing stuff on the heap isn't particularly significant), but be careful of simplifications that will cause problems down the line. Distinguishing "small values" from "big values" leads to the obvious question: Which is which? And why doesn't this work? >>> x = 3000 >>> z = x >>> z is x True Seems legit... you set z equal to x, and then z is the same as x. Okay, let's try that slightly differently. >>> x = 1000 >>> y = 2000 >>> z = x + y >>> z is 3000 False What's different? How come I can do comparisons with 'is' sometimes but not other times? (And just to make things more confusing, if you do this in CPython with small numbers, it'll *seem* to work.) The only way to explain it thoroughly is to fully distinguish between names and objects, and explain what assignment actually means. Then it's obvious that, in the first case, the identity check passes, while in the second case, it doesn't. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-14 23:43 +0200 |
| Message-ID | <87mwhtnzdu.fsf@elektro.pacujo.net> |
| In reply to | #66329 |
Chris Angelico <rosuav@gmail.com>: > be careful of simplifications that will cause problems down the line. Sure. Let it be said, though, that sometimes you learn through inaccuracies, a technique used intentionally by Knuth's TeXBook, for example. In fact, you get through highschool mathematics successfully without knowing what numbers and variables actually are. > 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. Back to the original question, though. Python, I think, is a great introductory programming language to a complete newbie. Explaining Python's memory model at some level is necessary right off the bat. However, it is far from easy to understand. I'm not sure the small/big way is the best approach, but it seeks to bridge the gap from the naive understanding of tutorial day one to the presented question (tutorial day two). Marko
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2014-02-14 19:00 -0500 |
| Message-ID | <mailman.6945.1392422451.18130.python-list@python.org> |
| In reply to | #66333 |
On 2/14/14 4:43 PM, Marko Rauhamaa wrote: > Chris Angelico<rosuav@gmail.com>: > >> >be careful of simplifications that will cause problems down the line. > Sure. Let it be said, though, that sometimes you learn through > inaccuracies, a technique used intentionally by Knuth's TeXBook, for > example. In fact, you get through highschool mathematics successfully > without knowing what numbers and variables actually are. > Yes, sometimes for teaching reasons, you have to over-simplify or even introduce artificial constructs. I'd recommend acknowledging them as such. When you say, "There are two fundamentally different kinds of values in Python," or "So we have four kinds of (memory) slots," you aren't letting on that this is a teaching construct. It sounds like you mean that this is how Python actually works. I'd use words like, "This is an oversimplification, but might help...", or "You can think of it like ...". -- Ned Batchelder, http://nedbatchelder.com
[toc] | [prev] | [next] | [standalone]
| From | dave em <daveandem2000@gmail.com> |
|---|---|
| Date | 2014-02-14 16:26 -0800 |
| Message-ID | <f0b247c8-c44e-4d91-809d-9223b9af13b8@googlegroups.com> |
| In reply to | #66340 |
All, Thanks for the excellent explanations and for sharing your knowledge. I definitely have a better understanding than I did this morning. Best regards, Dave
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 06:07 +0000 |
| Message-ID | <52ff041c$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66340 |
On Fri, 14 Feb 2014 19:00:36 -0500, Ned Batchelder wrote: > On 2/14/14 4:43 PM, Marko Rauhamaa wrote: >> Chris Angelico<rosuav@gmail.com>: >> >>> >be careful of simplifications that will cause problems down the line. >> Sure. Let it be said, though, that sometimes you learn through >> inaccuracies, a technique used intentionally by Knuth's TeXBook, for >> example. In fact, you get through highschool mathematics successfully >> without knowing what numbers and variables actually are. >> >> > Yes, sometimes for teaching reasons, you have to over-simplify or even > introduce artificial constructs. I'd recommend acknowledging them as > such. The mathematician Ian Stewart and biologist Jack Cohen call these "lies for children". They don't mean it as a pejorative. In fact, calling them "lies for children" is itself a lie for children :-) (Lies for children are not lies, nor are they just for children.) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 11:00 +0200 |
| Message-ID | <877g8woim9.fsf@elektro.pacujo.net> |
| In reply to | #66340 |
Ned Batchelder <ned@nedbatchelder.com>: > On 2/14/14 4:43 PM, Marko Rauhamaa wrote: > Yes, sometimes for teaching reasons, you have to over-simplify or even > introduce artificial constructs. I'd recommend acknowledging them as > such. > > When you say, "There are two fundamentally different kinds of values > in Python," or "So we have four kinds of (memory) slots," you aren't > letting on that this is a teaching construct. It sounds like you mean > that this is how Python actually works. > > I'd use words like, "This is an oversimplification, but might > help...", or "You can think of it like ...". Strictly speaking, I'm not simplifying, but giving an equivalent, alternative description. I admit that the word "fundamentally" was a bad choice. I'm not even sure my description was a good illustration. I definitely was not referring to CPython and was trying to keep the discussion separate from the implementation of the day. BTW, I also wasn't oversimplifying, but complicating by bringing in an unnecessary dichotomy. The challenge is how to present Python's value model in the most digestible way. For example, how is a beginnger to understand what's going on in: n += 1 Is it easier to think that the number held by the variable n is incremented by 1, or is it easier to understand it orthodoxly through instantiations and references? Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 11:57 +1100 |
| Message-ID | <mailman.6947.1392425862.18130.python-list@python.org> |
| In reply to | #66333 |
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? 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. The only situation I can think of is that immutables are allowed to be interned, which is why this comes up True (in CPython) when it would come up False with larger values (as I demonstrated earlier): >>> x = 1 >>> y = 2 >>> z = x + y >>> z is 3 True ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-14 17:55 -0800 |
| Message-ID | <59c876d3-02f5-4f5a-8728-a5098472e03d@googlegroups.com> |
| In reply to | #66343 |
On Saturday, February 15, 2014 6:27:33 AM UTC+5:30, Chris Angelico wrote: > On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa 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? 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. Fundamentally your definition above is circular: In effect the python expr "a is b" is the same as a is b. The only way to move ahead on that circularity is to 'leak-out' the under-belly of python's object-model. 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 :-)
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 13:08 +1100 |
| Message-ID | <mailman.6950.1392430127.18130.python-list@python.org> |
| In reply to | #66345 |
On Sat, Feb 15, 2014 at 12:55 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Saturday, February 15, 2014 6:27:33 AM UTC+5:30, Chris Angelico wrote:
>> 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
>
> Fundamentally your definition above is circular: In effect
> the python expr "a is b" is the same as a is b.
It's not circular, it's stating the definition of the operator. And
since the definition is so simple, it's impossible - at that level -
for it to be ambiguous. It's possible for equality to be ambiguous, if
you have two types which define __eq__:
class Everyone:
def __eq__(self, other): return True
class Noone:
def __eq__(self, other): return False
>>> Everyone()==Noone()
True
>>> Noone()==Everyone()
False
But it's not possible for 'is' to behave like that.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-14 18:34 -0800 |
| Message-ID | <c699d08e-fd66-4aa2-a2b1-d936d7825be5@googlegroups.com> |
| In reply to | #66346 |
On Saturday, February 15, 2014 7:38:39 AM UTC+5:30, Chris Angelico wrote: > On Sat, Feb 15, 2014 at 12:55 PM, Rustom Mody wrote: > > On Saturday, February 15, 2014 6:27:33 AM UTC+5:30, Chris Angelico wrote: > >> 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 > > Fundamentally your definition above is circular: In effect > > the python expr "a is b" is the same as a is b. > It's not circular, it's stating the definition of the operator. And > since the definition is so simple, it's impossible - at that level - > for it to be ambiguous. It's possible for equality to be ambiguous, if > you have two types which define __eq__: At what level can you explain the following? >>> x = 1234567 * 1234567 >>> x 1524155677489L >>> y = 1234567 * 1234567 >>> y 1524155677489L >>> x is y False >>> 1524155677489 == x True >>> 1524155677489 is x False >>> As against >>> x = 2*3 >>> y= 2*3 >>> x == y True >>> x is y True >>> 6 is x True >>> "Interning" you will say. Is interning a simple matter for example at the level of questioning of the OP?
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 13:42 +1100 |
| Message-ID | <mailman.6951.1392432144.18130.python-list@python.org> |
| In reply to | #66350 |
On Sat, Feb 15, 2014 at 1:34 PM, Rustom Mody <rustompmody@gmail.com> wrote: > At what level can you explain the following? > >>>> x = 1234567 * 1234567 >>>> x > 1524155677489L Well, for a start, I'd use Python 3, so there's no need to explain why some numbers have an L after them :) > As against > >>>> x = 2*3 >>>> 6 is x > True > > "Interning" you will say. > Is interning a simple matter for example at the level of questioning of the OP? 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. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-14 19:14 -0800 |
| Message-ID | <6e96ba97-8ad0-4dad-9d11-b27bf9b237d0@googlegroups.com> |
| In reply to | #66351 |
On Saturday, February 15, 2014 8:12:14 AM UTC+5:30, Chris Angelico wrote: > On Sat, Feb 15, 2014 at 1:34 PM, Rustom Mody wrote: > > At what level can you explain the following? > >>>> x = 1234567 * 1234567 > >>>> x > > 1524155677489L > 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 > > As against > >>>> x = 2*3 > >>>> 6 is x > > True > > "Interning" you will say. > > Is interning a simple matter for example at the level of questioning of the OP? > 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 ------------- "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 As a teacher Ive done more than my fair share of all especially 3 but if you have a 4th option Id be interested to know! Philosophically"to be" called the copula is such a knotty problem that there is an entire movement to create a version of English without any form of "is,are,be" etc http://en.wikipedia.org/wiki/E-Prime
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 14:33 +1100 |
| Message-ID | <mailman.6955.1392435220.18130.python-list@python.org> |
| In reply to | #66352 |
On Sat, Feb 15, 2014 at 2:14 PM, Rustom Mody <rustompmody@gmail.com> 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. 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. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web