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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2014-02-14 13:42 -0500 |
| Message-ID | <mailman.6925.1392403361.18130.python-list@python.org> |
| In reply to | #66310 |
On 2/14/14 1:08 PM, dave em wrote: > 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 > Names in Python refer to values. Thinking in terms of memory locations might just confuse things. This is my best explanation of the details: http://nedbatchelder.com/text/names.html -- Ned Batchelder, http://nedbatchelder.com
[toc] | [prev] | [next] | [standalone]
| From | Ryan Gonzalez <rymg19@gmail.com> |
|---|---|
| Date | 2014-02-14 12:31 -0600 |
| Message-ID | <mailman.6926.1392405732.18130.python-list@python.org> |
| In reply to | #66310 |
[Multipart message — attachments visible in raw view] — view raw
On 02/14/2014 12:08 PM, dave em wrote: > 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 You've got it backwards. In Python, /everything/ is a reference. The variable is just a "pointer" to the actual value. When you change a variable, you're just changing the memory location it points to. Strings, ints, tuples, and floats behave differently because they're /immutable/. That means that they CANNOT modify themselves. That's why all of the string methods return a new string. It also means that, when you pass one two a function, a /copy/ of it is made and passed instead. So, back to the original subject. Everything is a reference. When you do this: |x = [1,2,3] x = [4,5,6] | x now points to a different memory location. And, when you do this: |x[0] =99000 x[0] =100 | you're just changing the memory location that |x[0]| points to. -- --Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 05:36 +0000 |
| Message-ID | <52fefccc$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66316 |
On Fri, 14 Feb 2014 12:31:56 -0600, Ryan Gonzalez wrote:
> On 02/14/2014 12:08 PM, dave em wrote:
>> 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
>
> You've got it backwards. In Python, /everything/ is a reference.
What's a reference?
How is the value 23 a reference? What is it a reference to?
> The
> variable is just a "pointer" to the actual value. When you change a
> variable, you're just changing the memory location it points to.
What do memory locations have to do with Python code? When I execute
Python code in my head, perhaps using a pencil and paper, or build a
quantum computer (or analog clockwork device) to execute Python code,
where are the memory locations?
I think you are conflating the *implementation* of Python's virtual
machine in a C-like language written for a digital computer with the
*defined behaviour* of the Python virtual machine. If you think about the
Python execution model, there is almost nothing about memory locations in
it. The only exception I can think of is the id() function, which uses
the memory address of the object as the ID, and even that is *explicitly*
described as an implementation detail and not a language feature. And in
fact Jython and IronPython assign IDs to objects consecutively from 1,
and PyPy has to go through heroic and complicated measures to ensure that
objects have the same ID at all times.
Thinking about the implementation of Python as written for certain types
of digital computing devices can be useful, but we must be very careful
to avoid mixing up details at the underlying C (or Java, or Haskell, or
Lisp, or ...) layer with questions about the Python execution model.
As soon as you mention "pointers", you're in trouble, because Python has
no pointers. There is nothing in Python that will give you a pointer to
an object, or dereference a pointer to get the object at the other end.
Pointers in the sense of C or Pascal pointers to memory addresses simply
don't have any existence in Python. Python compilers can even be written
in languages like Java that don't have pointers. The fact that the C
implementation of Python uses pointers internally is not very
interesting, any more than the fact that a Python implementation running
on a Turing Machine would use a pencil and eraser that can draw marks on
a very long paper tape.
> Strings, ints, tuples, and floats behave differently because they're
> /immutable/. That means that they CANNOT modify themselves. That's why
> all of the string methods return a new string. It also means that, when
> you pass one two a function, a /copy/ of it is made and passed instead.
Yes, strings etc. are immutable, but no, they are not copied when you
pass them to a function. We can be sure of this for two reasons:
(1) We can check the id() of the string from the inside and the outside
of the function, and see that they are the same; and
(2) We can create a HUGE string, hundreds of megabytes, and pass it to
dozens of functions, and see no performance slowdown. It might take a
second or five to build the initial string, and microseconds or less to
pass it to function after function after function.
> So, back to the original subject. Everything is a reference.
To really under stand Python's behaviour, we need to see that there are
two kinds of entities, names and values. Or another way to put it,
references and objects. Or another way to put it, there's actually only
one kind of thing in Python, that is, everything in Python is an object,
but Python *code* can refer to objects indirectly by names and other
references. Names aren't "things", but the things that names refer to are
things.
Objects have a clear definition in the Python world: they are an entity
that has a type (e.g. a string), a set of behaviour (methods), and a
value ("Hello World").
References can be names like `mystring`, or list items `mylist[0]`, or
items in mappings `mydict["key"]`, or attributes `myobject.attr`, or even
expressions `x+y*(1-z)`. References themselves aren't "things" as such
(although in Python, *names* are implemented as string keys in
namespaces), but a way to indirectly refer to things (values, objects).
> When you do this:
>
> x = [1,2,3]
> x = [4,5,6]
>
> x now points to a different memory location.
Memory locations are irrelevant. Objects may not even have a single, well-
defined memory location. (If you think this is impossible, you're
focusing too much on a single computer architecture.) They might use some
sort of copy-on-write mechanism so that objects don't even exist until
you modify them. Who knows?
Instead, we should say that x now refers to a different object.
An analogy, the name "President of the United States" stopped referring
to George Bush Jr and started referring to Barack Obama a few years back,
but the "objects" (people) have an existence separate from the name used
to refer to them.
(By the way, I try to avoid using the term "points to" if I can, since it
has connotations to those familiar with C which don't apply to Python.)
> And, when you do this:
>
> x[0] =99000
> x[0] =100
>
> you're just changing the memory location that |x[0]| points to.
Again, I'd say that x[0] now refers to a different object.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 17:07 +1100 |
| Message-ID | <mailman.6966.1392444446.18130.python-list@python.org> |
| In reply to | #66372 |
On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > References can be names like `mystring`, or list items `mylist[0]`, or > items in mappings `mydict["key"]`, or attributes `myobject.attr`, or even > expressions `x+y*(1-z)`. I agree with most of what you've said, but I'm not sure I like that last bit. The expression evaluates to an object, yes, but it's not itself a reference... is it? It has references to x, y, 1, and z, but it's not itself a reference to anything. If you take a reference and assign it to a name, and take that same reference and assign it to another name, I would expect those two names to now refer to the same object: >>> lst = [1000, 2000, 3000] >>> x = lst[1] >>> y = lst[1] >>> x is y True But with expressions, it's not so, and new objects may be created. The expression isn't a reference to its result, but it can yield an object, which it (naturally) does by reference. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-15 06:48 +0000 |
| Message-ID | <52ff0dc5$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66376 |
On Sat, 15 Feb 2014 17:07:17 +1100, Chris Angelico wrote: > On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> References can be names like `mystring`, or list items `mylist[0]`, or >> items in mappings `mydict["key"]`, or attributes `myobject.attr`, or >> even expressions `x+y*(1-z)`. > > I agree with most of what you've said, but I'm not sure I like that last > bit. The expression evaluates to an object, yes, but it's not itself a > reference... is it? [snip discussion] You may be right. I will have to think about it a little more. Or a lot more. Ah wait, I got it: I chose a bad example for the expression. Here is a better one: myobj.alist[12]["some key"].attribute I think it is fair to call that both an expression and a reference. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 17:57 +1100 |
| Message-ID | <mailman.6970.1392447892.18130.python-list@python.org> |
| In reply to | #66384 |
On Sat, Feb 15, 2014 at 5:48 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Sat, 15 Feb 2014 17:07:17 +1100, Chris Angelico wrote: > >> On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano >> <steve+comp.lang.python@pearwood.info> wrote: >>> References can be names like `mystring`, or list items `mylist[0]`, or >>> items in mappings `mydict["key"]`, or attributes `myobject.attr`, or >>> even expressions `x+y*(1-z)`. >> >> I agree with most of what you've said, but I'm not sure I like that last >> bit. The expression evaluates to an object, yes, but it's not itself a >> reference... is it? > > You may be right. I will have to think about it a little more. Or a lot > more. Ah wait, I got it: I chose a bad example for the expression. Here > is a better one: > > myobj.alist[12]["some key"].attribute > > I think it is fair to call that both an expression and a reference. Sure. If it helps, the part that's a reference is the ".attribute" at the end; the rest is an expression which determines what object's attribute you're looking at. Same with the earlier parts; the [12] is a form of reference (albeit one that requires another object). But yes, this is an expression, and it evaluates to a reference. In any case, your main point is still valid: each of those forms will yield a reference to something. (Aside from the possibility of raising KeyError. As an expression, it has to yield a reference to an object.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-02-16 01:18 +1300 |
| Message-ID | <bm948tFht88U1@mid.individual.net> |
| In reply to | #66387 |
Chris Angelico wrote: > But yes, this is an expression, and it evaluates to a reference. Well, *all* expressions in Python evaluate to references, so that's not really saying much. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-15 23:24 +1100 |
| Message-ID | <mailman.6988.1392467055.18130.python-list@python.org> |
| In reply to | #66424 |
On Sat, Feb 15, 2014 at 11:18 PM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Chris Angelico wrote: >> >> But yes, this is an expression, and it evaluates to a reference. > > > Well, *all* expressions in Python evaluate to references, > so that's not really saying much. Because everything in Python is an object, and objects always are handled by their references. This wouldn't be true in every language (eg it's not true of Java's unboxed types), but it's intrinsic to Python's object model. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-02-15 15:25 +0200 |
| Message-ID | <87d2iomrsg.fsf@elektro.pacujo.net> |
| In reply to | #66426 |
Chris Angelico <rosuav@gmail.com>: > Because everything in Python is an object, and objects always are > handled by their references. This wouldn't be true in every language > (eg it's not true of Java's unboxed types), but it's intrinsic to > Python's object model. Well, it's part of Python's reference model. Any model that produces valid Python behavior is equally good. An implementation that boxes some or all immutable objects would still be perfectly valid. Anyway, an object is a fairly advanced and abstract concept. A beginning programmer wouldn't be equipped to understand the ultimate abstraction; an object is too all-encompassing to express anything. It might be productive to lead the aspirant to the mountain summit through a more concrete model. Identifying the references with RAM addresses and objects with RAM snippets might keep object tangible for the first few months, although a more mundane model would be welcome. I'm reminded of Raymond Smullyan's excellent "To Mock the Mockingbird," which models combinatory logic with a forest full of chirping birds. Marko
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-16 00:59 +1100 |
| Message-ID | <mailman.6997.1392472805.18130.python-list@python.org> |
| In reply to | #66431 |
Marko Rauhamaa <marko@pacujo.net> writes: > Anyway, an object is a fairly advanced and abstract concept. It is a concept that, in natural language, has the huge advantage of producing correct inferences most of the time. You don't need to give a formal definition when first introducing the term “object”. Just use it, and the student will produce inferences: * an object is a distinct concrete entity * an object is distinct from other objects * an object may or may not change, but remains the same object * an object belongs to a class of similar objects, and is different from objects of different classes * an object has behaviours that are mostly the same as other objects of the same class None of this needs to be spelled out when the term is introduced; all of it will follow from the connotations of the term “object” in English. > A beginning programmer wouldn't be equipped to understand the ultimate > abstraction; an object is too all-encompassing to express anything. Nevertheless, “object” as a term in normal English will produce a bunch of helpful inferences, and avoid the need for coming up with some less-familiar term. It will also allow you to postpone a formal definition until later. -- \ “Try to learn something about everything and everything about | `\ something.” —Thomas Henry Huxley | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-02-17 11:54 +1300 |
| Message-ID | <bmcttoFcg7qU1@mid.individual.net> |
| In reply to | #66426 |
Chris Angelico wrote: > Because everything in Python is an object, and objects always are > handled by their references. <beginner_thought> So, we have objects... and we have references to objects... but everything is an object... so does that mean references are objects too? </beginner_thought> This is the kind of trouble you get into when you make a statement of the form "everything is an X"[1]. When we say "everything is an object", we don't literally mean everything, only... well, those things that *are* objects. Which doesn't really help the beginner much. [1] Mathematicians tried this. "Everything is a set!" Yeah, right... -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-17 10:02 +1100 |
| Message-ID | <mailman.7073.1392591754.18130.python-list@python.org> |
| In reply to | #66568 |
On Mon, Feb 17, 2014 at 9:54 AM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Chris Angelico wrote: >> >> Because everything in Python is an object, and objects always are >> handled by their references. > > > <beginner_thought> So, we have objects... and we have > references to objects... but everything is an object... > so does that mean references are objects too? > </beginner_thought> References aren't themselves objects. Names, attributes, etc, etc, etc, all refer to objects. Is it clearer to use the verb "refer" rather than the noun "reference"? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-02-16 18:46 -0500 |
| Message-ID | <roy-9A7123.18461016022014@news.panix.com> |
| In reply to | #66569 |
In article <mailman.7073.1392591754.18130.python-list@python.org>, Chris Angelico <rosuav@gmail.com> wrote: > On Mon, Feb 17, 2014 at 9:54 AM, Gregory Ewing > <greg.ewing@canterbury.ac.nz> wrote: > > Chris Angelico wrote: > >> > >> Because everything in Python is an object, and objects always are > >> handled by their references. > > > > > > <beginner_thought> So, we have objects... and we have > > references to objects... but everything is an object... > > so does that mean references are objects too? > > </beginner_thought> > > References aren't themselves objects. Names, attributes, etc, etc, > etc, all refer to objects. Is it clearer to use the verb "refer" > rather than the noun "reference"? > > ChrisA I know functions are objects, but what about statements? Is the body of a for loop an object? It is in some languages.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-17 12:26 +1100 |
| Message-ID | <mailman.7076.1392600406.18130.python-list@python.org> |
| In reply to | #66572 |
On Mon, Feb 17, 2014 at 10:46 AM, Roy Smith <roy@panix.com> wrote: >> References aren't themselves objects. Names, attributes, etc, etc, >> etc, all refer to objects. Is it clearer to use the verb "refer" >> rather than the noun "reference"? >> >> ChrisA > > I know functions are objects, but what about statements? Is the body of > a for loop an object? It is in some languages. And *that* is an extremely fair question. The best explanation I can come up with is somewhat circular: If it can be named in the code, it's an object. What that really means is that every object is first-class (contrast, for instance, C's arrays and functions), but it doesn't answer the actual question of what's an object and what's not. But my advice would be to try things in the interactive interpreter. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-17 10:05 +1100 |
| Message-ID | <mailman.7074.1392591962.18130.python-list@python.org> |
| In reply to | #66568 |
Gregory Ewing <greg.ewing@canterbury.ac.nz> writes: > Chris Angelico wrote: > > Because everything in Python is an object, and objects always are > > handled by their references. > > <beginner_thought> So, we have objects... and we have > references to objects... but everything is an object... > so does that mean references are objects too? > </beginner_thought> My response: No, because references are not things :-) I've never known a programming beginner to express such a question. Have you? Were they beginners at programming, or experienced programmers who were coming to Python with the data models of other languages already in their head? -- \ “Computer perspective on Moore's Law: Human effort becomes | `\ twice as expensive roughly every two years.” —anonymous | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-02-16 18:43 -0500 |
| Message-ID | <roy-29042D.18431516022014@news.panix.com> |
| In reply to | #66570 |
In article <mailman.7074.1392591962.18130.python-list@python.org>, Ben Finney <ben+python@benfinney.id.au> wrote: > Gregory Ewing <greg.ewing@canterbury.ac.nz> writes: > > > Chris Angelico wrote: > > > Because everything in Python is an object, and objects always are > > > handled by their references. > > > > <beginner_thought> So, we have objects... and we have > > references to objects... but everything is an object... > > so does that mean references are objects too? > > </beginner_thought> > > My response: No, because references are not things :-) > > I've never known a programming beginner to express such a question. Have > you? You make light of Gregory's point, but he's right. That's exactly the kind of thing a beginner would get confused about.
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-17 11:04 +1100 |
| Message-ID | <mailman.7075.1392595501.18130.python-list@python.org> |
| In reply to | #66571 |
Roy Smith <roy@panix.com> writes: > In article <mailman.7074.1392591962.18130.python-list@python.org>, > Ben Finney <ben+python@benfinney.id.au> wrote: > > > Gregory Ewing <greg.ewing@canterbury.ac.nz> writes: > > > <beginner_thought> So, we have objects... and we have references > > > to objects... but everything is an object... so does that mean > > > references are objects too? </beginner_thought> > > > > My response: No, because references are not things :-) > > > > I've never known a programming beginner to express such a question. Have > > you? > > You make light of Gregory's point, but he's right. That's exactly the > kind of thing a beginner would get confused about. That's exactly what I'm asking: What beginners actually do get confused about this? What category of beginner are they, and how di different categories of beginner approach this differently? In other words, rather than asserting based on anecdotes, what *actually* happens? Let's examine what leads them to this confusion, as a starting point for what can be done. -- \ “Odious ideas are not entitled to hide from criticism behind | `\ the human shield of their believers' feelings.” —Richard | _o__) Stallman | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-17 06:31 +0000 |
| Message-ID | <5301acb6$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66571 |
On Sun, 16 Feb 2014 18:43:15 -0500, Roy Smith wrote:
> In article <mailman.7074.1392591962.18130.python-list@python.org>,
> Ben Finney <ben+python@benfinney.id.au> wrote:
>
>> Gregory Ewing <greg.ewing@canterbury.ac.nz> writes:
>>
>> > Chris Angelico wrote:
>> > > Because everything in Python is an object, and objects always are
>> > > handled by their references.
>> >
>> > <beginner_thought> So, we have objects... and we have references to
>> > objects... but everything is an object... so does that mean
>> > references are objects too? </beginner_thought>
>>
>> My response: No, because references are not things :-)
>>
>> I've never known a programming beginner to express such a question.
>> Have you?
>
> You make light of Gregory's point, but he's right. That's exactly the
> kind of thing a beginner would get confused about.
I take it that you haven't spent much time around beginners? Perhaps you
should spend some time on the "tutor" mailing list. If you do, you will
see very few abstract or philosophical questions such as whether
references are themselves things or what identity means. But you will
find plenty of questions about:
- "Will you do my homework for me?"
- "What's this syntax error mean?" (very rarely with the syntax
error actually shown)
- confusion about the fundamentals of sequential algorithms, e.g.
asking why this loop always prints the same value forever:
var = random.randint(1, 10)
while var != 10:
print(var)
and similar sorts of *concrete* problems.
Just about the only abstract question that I've seen from beginners is
the question "What's object oriented programming?" In my experience,
people don't start asking abstract questions until they've been
programming for a few years.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-17 05:43 -0800 |
| Message-ID | <b9203e71-1054-4fca-8c31-9a9afe03fa20@googlegroups.com> |
| In reply to | #66588 |
On Monday, February 17, 2014 12:01:18 PM UTC+5:30, Steven D'Aprano wrote: > I take it that you haven't spent much time around beginners? Perhaps you > should spend some time on the "tutor" mailing list. If you do, you will > see very few abstract or philosophical questions such as whether > references are themselves things or what identity means. But you will > find plenty of questions about: > - "Will you do my homework for me?" Right And what that 'homework' consists of is determined by the educational context of the questioner. 'Teacher' is of course a big but hardly exclusive part of that 'Syllabus-setters' (who can be more clueless than teachers) are another 'Other attendant factors' big one being programming language. Hang out on a Haskell list and you will get questions about - category theory - typesystems - structural induction and so on and so forth Does that mean Haskell is better than Python? That depends on which side of the balance-sheet is plus for you. For some getting the job done with a minimum of heavy-duty concepts is a plus For some lots of profound concepts is wonderful Basic to python philosophy is to get people off to a running start quickly. If NOT starting until you/your ward have mulled on some profundity is your thing then python is not for you
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2014-02-16 20:43 -0500 |
| Message-ID | <mailman.7077.1392601440.18130.python-list@python.org> |
| In reply to | #66568 |
On 2/16/14 5:54 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> Because everything in Python is an object, and objects always are >> handled by their references. > > <beginner_thought> So, we have objects... and we have > references to objects... but everything is an object... > so does that mean references are objects too? > </beginner_thought> > > This is the kind of trouble you get into when you make > a statement of the form "everything is an X"[1]. When > we say "everything is an object", we don't literally > mean everything, only... well, those things that *are* > objects. Which doesn't really help the beginner much. > > [1] Mathematicians tried this. "Everything is a set!" > Yeah, right... > The correct statement is "all values are objects", or "all data is objects". When people mistakenly say "everything is an object", they are implicitly only thinking about data. That said, "all data is objects" is really mostly useful in contrast to other languages where some data is objects and some is not. I think Ben Finney's point from nearby in this thread is spot on: there's a huge difference between a beginning programmer and an experienced programmer new to Python. The latter category is sometimes the harder to teach, because you have to undo the things they learned about their earlier language X, but which they mistakenly believe to be true about all programming languages. -- Ned Batchelder, http://nedbatchelder.com
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web