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 | 16 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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-17 12:59 +1100 |
| Message-ID | <mailman.7079.1392602374.18130.python-list@python.org> |
| In reply to | #66568 |
On Mon, Feb 17, 2014 at 12:43 PM, Ned Batchelder <ned@nedbatchelder.com> wrote:
> 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.
Part of the trouble is that some code is (represented by) objects. A
function is an object, ergo it's data; a module is an object (though
that's different); a class is an object; but no other block of code
is. You can't give a name to a while loop, then pick it up and use it
somewhere else.
x = while input("Guess my number: ")!="42":
print("Wrong number, try again.")
So a while loop isn't data. But wrap it in a function and suddenly it is:
def x():
while input("Guess my number: ")!="42":
print("Wrong number, try again.")
y = x
func(x)
etc
So when does code become data? When it's represented by an object.
What's an object and what's not? Data is objects, non-data is not. And
we're back to being circular again. (Does this mean we're having a
circular discussion about circular definitions?)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-02-16 22:28 -0500 |
| Message-ID | <roy-1F9D59.22282316022014@news.panix.com> |
| In reply to | #66578 |
In article <mailman.7079.1392602374.18130.python-list@python.org>, Chris Angelico <rosuav@gmail.com> wrote: > On Mon, Feb 17, 2014 at 12:43 PM, Ned Batchelder <ned@nedbatchelder.com> > wrote: > > 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. > > Part of the trouble is that some code is (represented by) objects. A > function is an object, ergo it's data; a module is an object (though > that's different); a class is an object; but no other block of code > is. Lambda? > So when does code become data? When it's represented by an object. OK, now take somebody who knows lisp and try to explain to him or her why Python's eval() doesn't mean data is code. Yeah, I know that's pushing things a bit, but I'm trying to point out that people come into things with pre-conceived notions that are hard to shake (the psychology of learning people would call this the Law of Primacy).
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-17 14:52 +1100 |
| Message-ID | <mailman.7081.1392609174.18130.python-list@python.org> |
| In reply to | #66581 |
Roy Smith <roy@panix.com> writes: > Chris Angelico <rosuav@gmail.com> wrote: > > Part of the trouble is that some code is (represented by) objects. A > > function is an object, ergo it's data; a module is an object (though > > that's different); a class is an object; but no other block of code > > is. > > Lambda? The ‘lambda’ syntax creates a function. It doesn't create “a lambda”; there's no distinction between functions that were created with a ‘def’ statement versus a ‘lambda’ expression. -- \ “Generally speaking, the errors in religion are dangerous; | `\ those in philosophy only ridiculous.” —David Hume, _A Treatise | _o__) of Human Nature_, 1739 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-02-16 20:35 -0800 |
| Message-ID | <e5f4b3dd-d0b7-4f6e-acf0-f528c3aa6a42@googlegroups.com> |
| In reply to | #66581 |
On Monday, February 17, 2014 8:58:23 AM UTC+5:30, Roy Smith wrote: > Chris Angelico wrote: > > > 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. > > Part of the trouble is that some code is (represented by) objects. A > > function is an object, ergo it's data; a module is an object (though > > that's different); a class is an object; but no other block of code > > is. > Lambda? > > So when does code become data? When it's represented by an object. > OK, now take somebody who knows lisp and try to explain to him or her > why Python's eval() doesn't mean data is code. Yeah, I know that's > pushing things a bit, but I'm trying to point out that people come into > things with pre-conceived notions that are hard to shake (the psychology > of learning people would call this the Law of Primacy). More true than you (probably) know. No Ive not seen a newcomer to python who is an old hand at lisp* What Ive seen is: 25 years ago a 'newcomer' -- like all python objects are objects -- was a newcomer. One of the things I learnt early was that kids were terrified of a beastie that has two modes -- one in which it beeps and the other in which it corrupts the file -- also called 'vi.' Add to that C and pointers and all that and it was just too much. So my first assignment was not programming but just to type a poem. Nowadays the 'newcomers' come with half a dozen computers -- including the phones in their pockets. They know all sorts of technologies that I dont -- Whats a raspberry-pi or an xbox? I frankly dont know more than the names All of them seem to use their phones more savvily than I do! So I cannot even effectively evaluate what percentage of their knowledge is ok, what confused and what balderdash. No -- a clean slate is not a realistic luxury in 2014. * with the exception of yours truly 12 years ago
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-17 08:03 +0000 |
| Message-ID | <5301c238$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66581 |
On Sun, 16 Feb 2014 22:28:23 -0500, Roy Smith wrote:
>> So when does code become data? When it's represented by an object.
>
> OK, now take somebody who knows lisp and try to explain to him or her
> why Python's eval() doesn't mean data is code. Yeah, I know that's
> pushing things a bit, but I'm trying to point out that people come into
> things with pre-conceived notions that are hard to shake (the psychology
> of learning people would call this the Law of Primacy).
There are ways to treat code as values:
- you can use a string (an object/value) representing source code;
- you can create a code object using compile(), passing it a string;
- you can eval or exec on a string or a code object;
- you can extract bits and pieces of function objects;
and possibly others.
But, and I think this is critical, you can't evaluate source code
directly in Python. You can only do so indirectly, after creating some
sort of object: a string, a code object, a function, etc. There is always
an intermediate step: first, create a string object, then treat it as
code. There's no functionality in Python for taking source code directly
*as source code* and treating it as a value:
function(import this)
doesn't work, because `import this` is not a value that can be passed to
the function. You have to make it a string first:
function("import this")
The Python compiler can check the syntax of actual source code at compile
time, but it can't do anything about mock source code until runtime when
you pass it to exec, eval or compile. That's because until that moment,
it's just a string of characters, not source code.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-02-17 06:21 +0000 |
| Message-ID | <5301aa63$0$29985$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #66568 |
On Mon, 17 Feb 2014 11:54:45 +1300, 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>
Every *thing* is an object. References aren't *things*. An analogy: there
is no thing "Greg Ewing" which is independent of you, there is you, the
thing with an independent existence, and then there is the reference (or
name), "Greg Ewing", a label for you.
But perhaps it is better to say that all *values* are objects.
> 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.
I don't believe that in Python there are any *things* (values) which
aren't objects. Even classes and exceptions are values. That's not the
case in all languages. In Java, you have objects, and you have unboxed
(native) types, and you have classes which aren't values at all. (Or at
least, not first-class values.)
So before you ask: for-loops aren't things (values). Neither are while-
loops, try...except blocks, pass statements, del statements, etc. Nor are
names and other references -- I believe that there is a practice in
certain areas of computer science to call them "l-values", which despite
the name are not values at all -- at least not in Python. Apart from
binding and unbinding:
ref = something()
del ref
which are somewhat special, you can't perform computations on
*references*, only on the things (values) which references refer to.
Contrast this to a hypothetical language which allowed you do perform
computations on references, say using a special ! operator:
# given
x = 23
XY = 42
# then
print (!x+"Y")
would print 42. The expression !x+"Y" operates on the reference itself,
and then print operates on the value referred to by that new reference.
> [1] Mathematicians tried this. "Everything is a set!" Yeah, right...
No, that's okay. You only get into trouble when you have self-referential
sets, like "the set of all sets that don't contain themselves".
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-17 18:11 +1100 |
| Message-ID | <mailman.7084.1392621097.18130.python-list@python.org> |
| In reply to | #66587 |
On Mon, Feb 17, 2014 at 5:21 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > So before you ask: for-loops aren't things (values). Neither are while- > loops, try...except blocks, pass statements, del statements, etc. Nor are > names and other references -- I believe that there is a practice in > certain areas of computer science to call them "l-values", which despite > the name are not values at all -- at least not in Python. Usually an l-value is something that can go on the left side of assignment, and an r-value is something that can go on the right side of assignment. (In most languages, every l-value is also an r-value, by definition.) In C, for instance, any simple variable is an l-value, except for those that are constants (you can't assign to an array). A dereferenced pointer is also an l-value, as is a structure element reference. An expression usually isn't (unless it results in a dereferenced pointer). C++ adds references. You can always assign to those (the assignment "happens" to the referred-to "thing"). Python says that these things can be assigned to: names, attributes (with dot), and items (with square brackets); I think that's it. Those are Python's l-values. Anything that evaluates to an object reference is an r-value, with the possible exception of function-local names that haven't been assigned to (does it count as "not an r-value" if trying to read it raises an exception?). Python's statements aren't values at all, and can't be referred to. (Though some of them, like class and def, do result in values or name bindings. But you can't refer to the def statement, only to the function object that it creates.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rotwang <sg552@hotmail.co.uk> |
|---|---|
| Date | 2014-02-17 18:24 +0000 |
| Message-ID | <ldtk57$sbp$1@dont-email.me> |
| In reply to | #66587 |
On 17/02/2014 06:21, Steven D'Aprano wrote: > On Mon, 17 Feb 2014 11:54:45 +1300, Gregory Ewing wrote: >> [...] >> >> [1] Mathematicians tried this. "Everything is a set!" Yeah, right... > > No, that's okay. You only get into trouble when you have self-referential > sets, like "the set of all sets that don't contain themselves". Actually there's nothing wrong with self-referential sets per se. For example set theory with Aczel's anti-foundation axiom instead of the axiom of foundation is consistent if ZF is; see e.g. http://en.wikipedia.org/wiki/Non-well-founded_set_theory The trouble comes not with self-reference, but with unrestricted comprehension.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2014-02-15 14:30 -0500 |
| Message-ID | <mailman.7020.1392492647.18130.python-list@python.org> |
| In reply to | #66384 |
On 15 Feb 2014 06:48:37 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:
>
>myobj.alist[12]["some key"].attribute
>
>
>I think it is fair to call that both an expression and a reference.
It's a chain of references to me...
The name myobj is a reference to some object that has a component
(attribute) named alist which is a reference to a list object. [12]
selects an element of the list, said element being an anonymous (unnamed,
unless you want to consider [12] to be the name) reference to an unnamed
dictionary object. "some key" selects an element of the dictionary which is
an anonymous reference to an object having an attribute named attribute
which itself is a reference to some object -- for the purposes of this
chain, the final mentioned object is considered the value of the fully
qualified name.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-02-14 16:37 -0500 |
| Message-ID | <mailman.6939.1392413895.18130.python-list@python.org> |
| In reply to | #66310 |
On 2/14/2014 1:08 PM, dave em wrote: > 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. The data model of C and other memory-oriented languages is *different* from the object model of Python and similar languages. The concept of 'memory address' is fundamental to C and absent from Python. To understand Python, one must think in terms of its referenced object model and not C's memory-address model. Consider name-binding statements, also called assignment statements. The simplest form is <name> = <expression> As always, the expression evaluates to a Python object. It may be an existing object or it may by a newly created. Either way, the name is associated with the object. Subsequent to the name binding, the name, as an expression, evaluates to the object it points to. An object can have 0 to many names associated with it. That set of names can change. A name can be associated with only one object at a time, but can be rebound to other objects. All objects have class (type) and a value. The value of some objects can be changed (lists, sets, dicts, most user-defined classes), others are fixed (numbers, strings, tuples, frozensets). a = 1 # a points to int object with value 1; a == 1 b = a # b points to the same int object; b == 1 and b is a a = '1' # a now points to a str object with value '1'; a == '1' c = [1,2,3] # c points to a list object whose value is the # given sequence of int objects; c == [1,2,3] d = c # d is the same list object as c d[1] = '2' # This associates the indicated 'slot' in the collection object d (which is also c) with a '2' string object. 'Variable' in C (a fixed memory location with a mutable value) is quite different from 'variable' in Python. Most people in Python mean a fixed name, potentially associated with a sequence of objects. In CPython, each object would usually be at a different C location. 'Variable' in math has multiple meanings. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | pecore@pascolo.net |
|---|---|
| Date | 2014-02-14 23:34 +0100 |
| Message-ID | <87iosh9vdv.fsf@pascolo.net> |
| In reply to | #66310 |
dave em <daveandem2000@gmail.com> 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.
s/list/mutable object/
# Mr Bond and Mr Tont are two different ob^H^H persons
james_bond = SecretAgent()
james_tont = SecretAgent()
# in some circles, Mr Bond is know as agent 007
agent_007 = james_bond
# Mr Bond, aka 007, is sent to the Caribbeans to crush Spectre
agent_007.move_to('Barbados')
print agent_007.location
print james_bond.location
# Mr Bond, alas, retires and his place in the Mi5 is taken, alas, by Mr Tont
agent_007 = james_tont
# Mr Tont, aka 007, is sent to Hong Kong to, to, whatever...
agent_007.move_to('Hong Kong')
print agent_007.location
print james_bond.location
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2014-02-15 10:38 +0100 |
| Message-ID | <ldncie$sm8$1@dont-email.me> |
| In reply to | #66310 |
Hi Dave, Am 14.02.14 19:08, schrieb dave em: > 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. as others have explained better and in more detail, there are mutable and immutable values. The point is, that in a=b and a[1] = x the "=" behaves differently. In the first case, you discard the reference, where a is pointing to, and bind to the same thing as b is pointing to. In the second case, you modify the thing that a is pointing to. Recently, we tripped upon such a thing in a bad way; we were doing least squares fitting with numpy, and the parameters passed through were modified in the residuals function. That caused the LS algorithm to fail. After we got suspicious about this, we tried to remedy by copying the parameters param_copy = param[:] It still didn't work, because a list behaves differently than a numpy array in this respect, to our big surprise: # list slicing, as we know it >>> a=[1,2,3,4] >>> b=a[:] # list slicing creates a copy >>> b[1]=123 >>> b [1, 123, 3, 4] >>> a [1, 2, 3, 4] # now numpy array slicing >>> import numpy as np >>> a=np.array([1, 2, 3, 4]) >>> a array([1, 2, 3, 4]) >>> b=a[:] # numpy slicing creates a reference >>> b[1]=123 >>> b array([ 1, 123, 3, 4]) >>> a array([ 1, 123, 3, 4]) Lesson learned: Don't modify parameters you got passed, if possible. It is rarely what you want and can sometimes even happen, when you know you don't want it. Christian
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2014-02-16 01:20 +1100 |
| Message-ID | <mailman.6999.1392474018.18130.python-list@python.org> |
| In reply to | #66310 |
Joshua Landau <joshua@landau.ws> writes: > Here, I give you a pdf. Hopefully this isn't anti > mailing-list-etiquette. This forum is read in many different contexts, and attachments aren't appropriate. You should simply put the text directly into your message, if it's short enough. If it's long, then put it online somewhere and send a link with a description; or, better, make it shorter so it is reasonable to put the text in a message :-) -- \ “Smoking cures weight problems. Eventually.” —Steven Wright | `\ | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-16 01:26 +1100 |
| Message-ID | <mailman.7001.1392474381.18130.python-list@python.org> |
| In reply to | #66310 |
On Sun, Feb 16, 2014 at 1:20 AM, Ben Finney <ben+python@benfinney.id.au> wrote: > Joshua Landau <joshua@landau.ws> writes: > >> Here, I give you a pdf. Hopefully this isn't anti >> mailing-list-etiquette. > > This forum is read in many different contexts, and attachments aren't > appropriate. You should simply put the text directly into your message, > if it's short enough. > > If it's long, then put it online somewhere and send a link with a > description; or, better, make it shorter so it is reasonable to put the > text in a message :-) I skimmed it, and... uhh... it's not text :) Well, it's mostly text, but it's arranged on the page with positioning and arrows and stuff. So a link would be more useful than trying to cram it into the post itself. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Joshua Landau <joshua@landau.ws> |
|---|---|
| Date | 2014-02-15 20:44 +0000 |
| Message-ID | <mailman.7022.1392497119.18130.python-list@python.org> |
| In reply to | #66310 |
On 15 February 2014 14:20, Ben Finney <ben+python@benfinney.id.au> wrote: > Joshua Landau <joshua@landau.ws> writes: > >> Here, I give you a pdf. Hopefully this isn't anti >> mailing-list-etiquette. > > This forum is read in many different contexts, and attachments aren't > appropriate. You should simply put the text directly into your message, > if it's short enough. > > If it's long, then put it online somewhere and send a link with a > description; or, better, make it shorter so it is reasonable to put the > text in a message :-) A PDF seemed like a better use of my time than ASCII art. Nevertheless, I agree that I can always give a link; I was just wondering if there was an environment under which this was actively harmful.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-02-16 09:27 +1100 |
| Message-ID | <mailman.7025.1392503229.18130.python-list@python.org> |
| In reply to | #66310 |
On Sun, Feb 16, 2014 at 7:44 AM, Joshua Landau <joshua@landau.ws> wrote: > On 15 February 2014 14:20, Ben Finney <ben+python@benfinney.id.au> wrote: >> Joshua Landau <joshua@landau.ws> writes: >> >>> Here, I give you a pdf. Hopefully this isn't anti >>> mailing-list-etiquette. >> >> This forum is read in many different contexts, and attachments aren't >> appropriate. You should simply put the text directly into your message, >> if it's short enough. >> >> If it's long, then put it online somewhere and send a link with a >> description; or, better, make it shorter so it is reasonable to put the >> text in a message :-) > > A PDF seemed like a better use of my time than ASCII art. > Nevertheless, I agree that I can always give a link; I was just > wondering if there was an environment under which this was actively > harmful. A PDF is fine. An attachment is problematic, and won't get to everyone. Hence the suggestion to put it online somewhere and post a link. (But be sure the host will be up for the next hundred years, ish.) ChrisA
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.python
csiph-web