Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #27634 > unrolled thread

Objects in Python

Back to article view | Back to comp.lang.python

Contents

  Objects in Python shaun <shaun.wiseman91@gmail.com> - 2012-08-22 07:13 -0700
    Re: Objects in Python Joel Goldstick <joel.goldstick@gmail.com> - 2012-08-22 10:31 -0400
    Re: Objects in Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-08-22 17:31 +0300
    Re: Objects in Python Peter Otten <__peter__@web.de> - 2012-08-22 16:36 +0200
    Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 15:59 +0100
      Re: Objects in Python MRAB <python@mrabarnett.plus.com> - 2012-08-22 16:58 +0100
        Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 17:10 +0100
          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 17:30 +0100
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 18:06 +0100
              Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 19:07 +0100
                Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 20:13 +0100
      Re: Objects in Python Terry Reedy <tjreedy@udel.edu> - 2012-08-22 13:01 -0400
        Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 18:46 +0100
          Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-22 12:15 -0600
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 20:03 +0100
              Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 12:02 +1000
                Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:11 +0000
                  Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 15:26 +1000
                  Re: Objects in Python Jan Kuiken <jan.kuiken@quicknet.nl> - 2012-08-23 20:02 +0200
                    Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-23 12:17 -0600
                      Re: Objects in Python Jan Kuiken <jan.kuiken@quicknet.nl> - 2012-08-23 22:43 +0200
                    Re: Objects in Python 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-25 23:14 -0700
          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 19:23 +0100
          Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-22 14:03 -0500
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-22 20:45 +0100
              Re: Objects in Python MRAB <python@mrabarnett.plus.com> - 2012-08-22 21:31 +0100
              Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 21:46 +0100
                Methods versus functions [was Re: Objects in Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:07 +0000
              Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-22 16:31 -0500
                Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 10:19 +0100
                  Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-23 11:44 -0500
                    Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 18:56 +0100
          Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-23 09:58 +1000
            Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-22 18:10 -0600
            Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-22 23:49 -0500
              Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 06:55 +0000
                Re: Objects in Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-08-23 11:59 +0300
                  Re: Objects in Python MRAB <python@mrabarnett.plus.com> - 2012-08-23 12:28 +0100
                  Re: Objects in Python Jerry Hill <malaclypse2@gmail.com> - 2012-08-23 10:43 -0400
                  Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-23 12:17 -0500
                    Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 17:56 +0000
                      Variables vs names [was: Objects in Python] Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-23 14:22 -0500
                        Re: Variables vs names Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 10:02 +1000
                        Re: Variables vs names [was: Objects in Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-25 02:05 +0000
                          Re: Variables vs names Ben Finney <ben+python@benfinney.id.au> - 2012-08-25 15:24 +1000
                      Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-24 08:00 +1000
                        Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-25 03:04 +0000
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-25 16:34 +1000
                          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-25 09:55 +0100
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-25 20:23 +1000
                          Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-25 12:01 +0100
                          Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-25 15:56 -0400
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 09:27 +1000
                          Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-25 20:43 -0400
                          Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-26 00:25 -0500
                      Re: Variables vs names [was: Objects in Python] Chris Angelico <rosuav@gmail.com> - 2012-08-24 09:34 +1000
                      Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 09:49 +1000
                      Re: Variables vs names [was: Objects in Python] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-23 19:52 -0400
                      Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-23 19:54 -0400
                      Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-24 10:01 +1000
                  Re: Objects in Python Terry Reedy <tjreedy@udel.edu> - 2012-08-23 13:17 -0400
              Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 00:16 +1000
              Re: Objects in Python Roy Smith <roy@panix.com> - 2012-08-23 20:36 -0400
                Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-24 11:34 +1000
                  Re: Objects in Python alex23 <wuwei23@gmail.com> - 2012-08-23 20:17 -0700
                    Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-24 04:14 -0500
                      Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-24 10:00 +0000
                        Re: Objects in Python Grant Edwards <invalid@invalid.invalid> - 2012-08-24 13:27 +0000
                          Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-25 05:18 +1000
                        Re: Re: Objects in Python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-08-26 00:45 -0500
                          Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 13:43 +0000
                            Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 23:58 +1000
                              Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 14:18 +0000
                                Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-27 00:54 +1000
                                  Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 22:47 +0000
                            Re: Objects in Python Roy Smith <roy@panix.com> - 2012-08-26 10:02 -0400
                              Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-27 00:14 +1000
                            Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-26 16:12 -0400
                              Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 23:29 +0000
                        Re: Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 16:22 +1000
                          Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-26 12:02 +0000
                            Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-26 23:34 +1000
                            Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-26 15:02 +0100
                            Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-27 00:05 +1000
                          Re: Objects in Python Roy Smith <roy@panix.com> - 2012-08-26 09:41 -0400
                Identity function id() [was Re: Objects in Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-24 10:06 +0000
            Re: Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 15:33 +1000
            Re: Objects in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-23 14:30 -0400
              Re: Objects in Python Alexander Blinne <news@blinne.net> - 2012-08-24 15:23 +0200
            Re: Objects in Python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2012-08-24 09:38 +0200
            Re: Objects in Python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2012-08-24 10:03 +0200
          Re: Objects in Python Walter Hurry <walterhurry@lavabit.com> - 2012-08-23 01:19 +0000
            Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:14 +0000
              Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 09:10 +0100
                Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-23 23:59 +1000
                  Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 15:20 +0100
                    Re: Objects in Python Ben Finney <ben+python@benfinney.id.au> - 2012-08-24 00:24 +1000
            Re: Objects in Python lipska the kat <lipskathekat@yahoo.co.uk> - 2012-08-23 09:03 +0100
          Re: Objects in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-08-23 04:34 +0000
            Re: Objects in Python rusi <rustompmody@gmail.com> - 2012-08-23 10:04 -0700
    Re: Objects in Python John Gordon <gordon@panix.com> - 2012-08-22 15:03 +0000
    Re: Objects in Python shaun <shaun.wiseman91@gmail.com> - 2012-08-22 08:25 -0700
      Re: Objects in Python Chris Angelico <rosuav@gmail.com> - 2012-08-23 01:47 +1000
      Re: Objects in Python Dave Angel <d@davea.name> - 2012-08-22 11:51 -0400
      Re: Objects in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-08-22 17:13 +0100
      Re: Objects in Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-08-22 11:29 -0600

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#27749

On 8/23/2012 10:43 AM, Jerry Hill wrote:

> Personally, when I was learning python I found the idea of python
> having names and values (rather than variables and references) to
> clear up a lot of my misconceptions of the python object model.  I
> think it's done the same for other people too, especially those who
> come from the C world, where a variable is a named and typed location
> in memory.

There are two important points about C and assembler. First, the named 
locations (and un-named internal locations like function return 
addresses) are *contiguous*. Giving a user access to one block may give 
a user access to other blocks if one is not careful. The other is that 
the typing is in the code and compiler, but not in the runtime memory. 
So text input can be read as code and a return jump address to the bytes 
interpreted as code.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#27735

[Multipart message — attachments visible in raw view] — view raw

Evan Driscoll <driscoll@cs.wisc.edu> writes:

> Especially the comparison to Java variables. Java programmers are
> quite used to variables which are references to objects: everything
> that's not a primitive type is a reference, and it's kinda hard to
> determine whether primitives are references or actual primitives.
>
> And many other languages have reference behavior and still call their
> bindings "variables", e.g. Scheme.

In these languages, programmers are presented with a data model that
emulates storage locations. A variable refers to a location, and
changing to a different object doesn't change the nominal location.

In Python, though, there is no such concept. A reference binds directly
to an object. If anything can be called a “variable”, it is the binding;
but the binding has no name and has no type, and there's nothing the
programmer can do with it except delete it. So it bears very little
useful connection with what most programmers will think of the term
“variable”.

-- 
 \        “I don't accept the currently fashionable assertion that any |
  `\       view is automatically as worthy of respect as any equal and |
_o__)                                   opposite view.” —Douglas Adams |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#27774

In article <mailman.3693.1345697563.4697.python-list@python.org>,
 Evan Driscoll <driscoll@cs.wisc.edu> wrote:

> > In fact, Python doesn't have variables ­ not as C or Java programmers
> > would understand the term. What it has instead are references to objects
> > (with names as one kind of reference).
> 
> OK, I've seen this said a few times, and I have to ask: what do you mean
> by this? I consider myself pretty decent at Python and other languages,
> and I really don't get it.

I'll take a shot at this.

When I execute:

a = 4

I'm doing two things.  The first is to create an object of type int with 
a value of 4.  I think everybody is OK with that part.  The confusing 
part comes with the LHS.

In C, or Java, there's a container called "a" which holds a value.  In 
C, that value is the integer 4, in Java it's an Integer object (well, at 
least I think it is, I've never fully groked how Java handles integers).

In Python, there is no container named "a".  There is, however, a dict 
which exists somewhere in python-space.  You can get a reference to this 
dict by calling globals().  What the assignment does is effectively:

globals()["a"] = 4

In fact, I can even write it that way and everything works:

>>> globals()["a"] = 42
>>> a
42

Even id() thinks they're the same thing:

>>> id(a)
1755402140
>>> id(globals()["a"])
1755402140

But, notice what happens if I now assign something new to a:

>>> a = 123
>>> id(a)
1755403176

The id has changed!  Now, we all know that the id of an object is its 
memory address (that's not guaranteed, but in the standard C 
implementation of Python, that's what it is).

Now, what if I do something similar in C:

#include <stdio.h>

main() {
    int a = 40;
    printf("a = %d, &a = %p\n", a, &a);
    a = 99;
    printf("a = %d, &a = %p\n", a, &a);
}

When I compile and run this, it prints:

a = 40, &a = 0x7fff1911f5bc
a = 99, &a = 0x7fff1911f5bc

Notice that the address of the variable "a" didn't change when I 
assigned it a new value.  That's what people mean when they say C has 
variables and Python doesn't; it just binds names to values.

[toc] | [prev] | [next] | [standalone]

#27775

On Fri, Aug 24, 2012 at 10:36 AM, Roy Smith <roy@panix.com> wrote:
> In fact, I can even write it that way and everything works:
>
>>>> globals()["a"] = 42
>>>> a
> 42
>
> Even id() thinks they're the same thing:
>
>>>> id(a)
> 1755402140
>>>> id(globals()["a"])
> 1755402140

Ah, no. What you have there is actually id(4) and nothing to do with a at all.

> But, notice what happens if I now assign something new to a:
>
>>>> a = 123
>>>> id(a)
> 1755403176
>
> The id has changed!  Now, we all know that the id of an object is its
> memory address (that's not guaranteed, but in the standard C
> implementation of Python, that's what it is).

And you now have id(123) - of course, it's possible for there to be
two integer objects with the value 123, but what I'm emphasizing is
that you're not looking at a here.

> Now, what if I do something similar in C:
>
> #include <stdio.h>
>
> main() {
>     int a = 40;
>     printf("a = %d, &a = %p\n", a, &a);
>     a = 99;
>     printf("a = %d, &a = %p\n", a, &a);
> }
>
> When I compile and run this, it prints:
>
> a = 40, &a = 0x7fff1911f5bc
> a = 99, &a = 0x7fff1911f5bc
>
> Notice that the address of the variable "a" didn't change when I
> assigned it a new value.  That's what people mean when they say C has
> variables and Python doesn't; it just binds names to values.

Try this instead. It's C++ not C but a much closer match. You could
instead play with malloc if you want it to be C.

#include <stdio.h>

main()
{
    int *a=new int(40);
    printf("a = %d, id(a) = %p\n",*a,a);
    a=new int(99);
    printf("a = %d, id(a) = %p\n",*a,a);
}

I've not tested the code and may have a syntax issue with "new
int(40)" (who ever allocates a single int on the heap??) but you get
the idea. At no point do you ever look at, or need to look at, &a.
That's utterly irrelevant.

ChrisA

[toc] | [prev] | [next] | [standalone]

#27776

On Aug 24, 11:34 am, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Aug 24, 2012 at 10:36 AM, Roy Smith <r...@panix.com> wrote:
> > Even id() thinks they're the same thing:
> >>>> id(a)
> > 1755402140
> >>>> id(globals()["a"])
> > 1755402140
>
> Ah, no. What you have there is actually id(4) and nothing to do with a at all.

Well, nothing expect for the fact that he's demonstrating Python
references and how they bind to objects. Sure, id() isn't doing any
lookup, but that's missing the point.

> > But, notice what happens if I now assign something new to a:
>
> >>>> a = 123
> >>>> id(a)
> > 1755403176
>
> > The id has changed!  Now, we all know that the id of an object is its
> > memory address (that's not guaranteed, but in the standard C
> > implementation of Python, that's what it is).
>
> And you now have id(123) - of course, it's possible for there to be
> two integer objects with the value 123, but what I'm emphasizing is
> that you're not looking at a here.

But Roy's point was that referring to 'a' as a 'variable' makes no
sense, as it's not an allocated piece of memory. In fact, he even said
"the id of an object" and not "the id of 'a'" so I'm not entirely sure
what you're objecting to here. You don't need to emphasise anything as
_that was the point_: you're _not_ looking at 'a' _ever_, you're only
ever looking at the object to which it refers.

[toc] | [prev] | [next] | [standalone]

#27787

[Multipart message — attachments visible in raw view] — view raw

On 8/23/2012 22:17, alex23 wrote:
> But Roy's point was that referring to 'a' as a 'variable' makes no
> sense, as it's not an allocated piece of memory.

Does the computer just remember what 'a' refers to by keeping notes
about it in Narnia?

Put it this way. If C removed the & operator -- and thus you couldn't
tell what address a variable (or "variable instance", if you prefer) was
at -- would "int x;" cease to be a variable?

Evan

[toc] | [prev] | [next] | [standalone]

#27788

On Fri, 24 Aug 2012 04:14:27 -0500, Evan Driscoll wrote:

> On 8/23/2012 22:17, alex23 wrote:
>> But Roy's point was that referring to 'a' as a 'variable' makes no
>> sense, as it's not an allocated piece of memory.
> 
> Does the computer just remember what 'a' refers to by keeping notes
> about it in Narnia?

No. The compiler remembers the address of 'a' by keeping notes about it 
somewhere in memory during the compilation process. When you run the 
compiled program, there is no longer any reference to the name 'a'.

(Many compilers give you the option to keep variable names, but that's 
additional debugging data, not an essential part of the execution model.)

The mapping of name:address is part of the *compilation* process -- the 
compiler knows that variable 'x' corresponds to location 12345678, but 
the compiled code has no concept of anything called 'x'. It only knows 
about locations. The source code 'x = 42' is compiled into something like 
'store 42 into location 12345678'. (Locations may be absolute or 
relative.)

In languages with name bindings, the compiler doesn't need to track 
name:address pairs. The compiled application knows about names, but not 
about addresses. The source code 'x = 42' is compiled into something like 
'store 42 into the namespace using key "x"'.

Python gives you no way to peek at an address. It's not even clear what 
the address of the variable would be, because there are *at least three* 
things it could be:

1) the address of the key field in the namespace (where the name lives);

2) the address of the value field in the namespace (where the pointer to 
the object lives);

3) the address of the object itself.

And any of these are free to move around during the lifetime of the 
application. (E.g. in Jython, which runs under the JVM, objects don't 
have a fixed location.)


> Put it this way. If C removed the & operator -- and thus you couldn't
> tell what address a variable (or "variable instance", if you prefer) was
> at -- would "int x;" cease to be a variable?

Not at all. Just because the public interface of the language doesn't 
give you any way to view the fixed locations of variables, doesn't mean 
that variables cease to have fixed locations.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27795

On 2012-08-24, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Fri, 24 Aug 2012 04:14:27 -0500, Evan Driscoll wrote:
>
>> On 8/23/2012 22:17, alex23 wrote:
>>> But Roy's point was that referring to 'a' as a 'variable' makes no
>>> sense, as it's not an allocated piece of memory.
>> 
>> Does the computer just remember what 'a' refers to by keeping notes
>> about it in Narnia?
>
> No. The compiler remembers the address of 'a' by keeping notes about it 
> somewhere in memory during the compilation process.

Ah, but as we are always fond of saying in this group "that's an
implementation detail, and not part of the language definition".  The
model where a compiler is "keeping notes about it in Narnia" is also
perfectly valid. However, RAM is easier to find than magic wardrobes,
so the "notes" are usually kept in RAM these days.

-- 
Grant Edwards               grant.b.edwards        Yow! You mean you don't
                                  at               want to watch WRESTLING
                              gmail.com            from ATLANTA?

[toc] | [prev] | [next] | [standalone]

#27822

On Fri, Aug 24, 2012 at 11:27 PM, Grant Edwards <invalid@invalid.invalid> wrote:
> Ah, but as we are always fond of saying in this group "that's an
> implementation detail, and not part of the language definition".  The
> model where a compiler is "keeping notes about it in Narnia" is also
> perfectly valid. However, RAM is easier to find than magic wardrobes,
> so the "notes" are usually kept in RAM these days.

Maybe, but once you found that wardrobe, you'd have enough storage for
all your needs, AND it takes no time at all to retrieve it! I think we
should start developing NarPy at once.

ChrisA

[toc] | [prev] | [next] | [standalone]

#27903

On 08/24/2012 05:00 AM, Steven D'Aprano wrote:
> No. The compiler remembers the address of 'a' by keeping notes about it
> somewhere in memory during the compilation process. When you run the
> compiled program, there is no longer any reference to the name 'a'.
>
> ...
>
> The mapping of name:address is part of the *compilation* process -- the
> compiler knows that variable 'x' corresponds to location 12345678, but
> the compiled code has no concept of anything called 'x'. It only knows
> about locations. The source code 'x = 42' is compiled into something like
> 'store 42 into location 12345678'. (Locations may be absolute or
> relative.)
>
> In languages with name bindings, the compiler doesn't need to track
> name:address pairs. The compiled application knows about names, but not
> about addresses. The source code 'x = 42' is compiled into something like
> 'store 42 into the namespace using key "x"'.
What you describe is sorta correct, but it's also not... you're 
describing implementations rather than the language. And while the 
language semantics certainly impose restrictions on the implementation, 
I think in this case the situation is closer than you acknowledge:


 From the Python side, I suspect that for most functions, you'd be able 
to create a Python implementation that behaves more like C, and 
allocates locals in a more traditional fashion. I don't know much about 
it, but I'd guess that PyPy already does something along this line; 
someone also mentioned that Cython (admittedly not a full-blown Python 
implementation, but close for the purpose of this question) tries to do 
the same thing.


On the C side, imagine a function with locals x, y, and z which never 
takes the address of any of them. (You said later that "Just because the 
public interface of the language doesn't give you any way to view the 
fixed locations of variables, doesn't mean that variables cease to have 
fixed locations.")

First, C variables may not even have a memory address. They can 
disappear completely during compilation, or live in a register for their 
entire life.

Second, it's possible that those variables *don't* occupy a fixed 
location. If you never explicitly take an address of a variable (&x), 
then I can't think of any way that the address can be observed without 
invoking undefined behavior -- and this means the C compiler is free to 
transform it to anything that is equivalent under the C semantics. In 
particular, it can split uses of a variable into multiple ones if there 
are disjoint live ranges. For instance, in:
     x = 5
     print x
     x = 10
     print x
there are two live ranges of x, one consisting of lines 1 and 2, and one 
consisting of lines 3 and 4. These live ranges could have been different 
variables; I could just of easily have written
     x = 5
     print x
     y = 10
     print y
and these pieces of code are observationally equivalent, so the compiler 
is allowed to generate the same code for both. In particular, it could 
either compile the second example to share the same memory address for x 
and y (meaning that a memory address isn't uniquely named by a single 
variable) or it could compile the first to put the two live ranges of x 
into different memory addresses (meaning that a variable doesn't 
uniquely name a memory address). In fact, I'd *expect* an optimizing 
compiler to share memory for x and y, and I'd also expect to be able to 
concoct an example where different live ranges of one variable wind up 
at different addresses. (The latter I'm less sure of though, and I also 
expect it'd be a little hard, as you'd have to come up with an example 
where even at the high optimization levels you'd need to see that, both 
live ranges would wind up in memory.)

Third, and more wackily, you could technically create a C implementation 
that works like Python, where it stores variables (whose addresses 
aren't taken) in a dict keyed by name, and generates code that on a 
variable access looks up the value by accessing that dict using the name 
of the variable.

Evan

[toc] | [prev] | [next] | [standalone]

#27921

On Sun, 26 Aug 2012 00:45:55 -0500, Evan Driscoll wrote:

> On 08/24/2012 05:00 AM, Steven D'Aprano wrote:
>> No. The compiler remembers the address of 'a' by keeping notes about it
>> somewhere in memory during the compilation process. When you run the
>> compiled program, there is no longer any reference to the name 'a'.
>>
>> ...
>>
>> The mapping of name:address is part of the *compilation* process -- the
>> compiler knows that variable 'x' corresponds to location 12345678, but
>> the compiled code has no concept of anything called 'x'. It only knows
>> about locations. The source code 'x = 42' is compiled into something
>> like 'store 42 into location 12345678'. (Locations may be absolute or
>> relative.)
>>
>> In languages with name bindings, the compiler doesn't need to track
>> name:address pairs. The compiled application knows about names, but not
>> about addresses. The source code 'x = 42' is compiled into something
>> like 'store 42 into the namespace using key "x"'.
>
> What you describe is sorta correct, but it's also not... you're
> describing implementations rather than the language. And while the
> language semantics certainly impose restrictions on the implementation,

I accept that languages may choose to leave the variable-model 
unspecified. I don't think they can define behaviour without implying one 
model or the other. Or at least not easily - far too much language 
behaviour is tied to the implementation to let us say "it's only 
implementation".

For example, the reason that locals() is not writable inside Python 
functions is because CPython moves away from the name binding model 
inside functions as an optimization. This function prints 1 under both 
CPython and Jython (but not IronPython):

def spam():
    x = 1
    locals()['x'] = 2
    print(x)

Binding to the local namespace does not work, because functions don't 
*actually* use a namespace, they use something closer to the C model. So 
the two models are not interchangable and hence they aren't *just* 
implementation details, they actually do affect the semantics of the 
language.

I suppose you could arrange for locals() to return a proxy dictionary 
which knew about the locations of variables. But what happens if you 
returned that proxy to the caller, which then assigned to it later after 
the function variables no longer existed?

Similarly, there are operations which are no longer allowed simply 
because of the difference between name binding and locational variables:


py> def ham():
...     from math import *
...
  File "<stdin>", line 1
SyntaxError: import * only allowed at module level


(In some older versions of Python, wildcard imports are allowed, and the 
function then falls back on a namespace instead of fixed locations. That 
is no longer the case in Python 3.2 at least.)


> I think in this case the situation is closer than you acknowledge:
> 
>  From the Python side, I suspect that for most functions, you'd be able
> to create a Python implementation that behaves more like C, and
> allocates locals in a more traditional fashion.

As I discuss above, CPython and Jython actually do something like that 
inside functions. And there are observable differences in behaviour (not 
just performance) between function scope and global scope.

So an implementation of Python which used fixed memory addresses 
everywhere, not just in functions, would be detectably different in 
behaviour than CPython. Whether those differences would be enough to 
disqualify it from being called "Python" is a matter of opinion.

(Probably Guido's opinion is the only one that matters.)


[...]
> On the C side, imagine a function with locals x, y, and z which never
> takes the address of any of them. (You said later that "Just because the
> public interface of the language doesn't give you any way to view the
> fixed locations of variables, doesn't mean that variables cease to have
> fixed locations.")
> 
> First, C variables may not even have a memory address. They can
> disappear completely during compilation, or live in a register for their
> entire life.

Variables that don't exist at runtime don't have an address at all -- in 
a way, they aren't even a variable any more. They have a name in the 
source code, but that's all.

As for registers, they are memory addresses, of a sort. (I didn't mean to 
imply that they must live in main motherboard memory.) I call any of 
these an address:

 - in the heap at address 12345678
 - in the GPU's video memory at address 45678
 - 12th entry from the top of the stack
 - register 4


> Second, it's possible that those variables *don't* occupy a fixed
> location. If you never explicitly take an address of a variable (&x),
> then I can't think of any way that the address can be observed without
> invoking undefined behavior -- and this means the C compiler is free to
> transform it to anything that is equivalent under the C semantics.

I may have been too emphatic about the "fixed" part. A sufficiently 
clever compiler may implement its own memory manager (on top of the 
operating system's memory manager?) and relocate variables during their 
lifetime. But for my purposes, the important factor is that the compiler 
knows the address at every moment, even if that address changes from time 
to time.

In contrast, a name binding system *doesn't* know the address of a 
variable. The analogy I like is making a delivery to a hotel room. C-like 
languages say:

"Deliver this package to room 1234."

Pointer semantics are like:

"Go to room 1234 and collect an envelope; deliver this package to the 
room number inside the envelope."

On the other hand, name binding languages say:

"Go to the concierge at the front desk and ask for Mr Smith's room, wait 
until he looks it up in the register, then deliver this package to the 
room number he tells you."

Typically, you don't even have any way to store the room number for later 
use. In Python, name lookups involve calculating a hash and searching a 
dict. Once you've looked up a name once, there is no way to access the 
hash table index to bypass that process for future lookups.

It gets worse: Python has multiple namespaces that are searched.

"Go to the Excelsior Hotel and ask the concierge for Mr Smith. If Mr 
Smith isn't staying there, go across the road to the Windsor Hotel and 
ask there. If he's not there, try the Waldorf Astoria, and if he's not 
there, try the Hyperion."

Considering just how much work Python has to do to simply access a named 
variable, it's amazing how slow it isn't.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27922

On Sun, Aug 26, 2012 at 11:43 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> It gets worse: Python has multiple namespaces that are searched.
>
> "Go to the Excelsior Hotel and ask the concierge for Mr Smith. If Mr
> Smith isn't staying there, go across the road to the Windsor Hotel and
> ask there. If he's not there, try the Waldorf Astoria, and if he's not
> there, try the Hyperion."

Does it? I thought the difference between function-scope and
module-scope was compiled in, and everything else boils down to one of
those. Explicit dot notation is different ("ask for Mr Smith, then ask
him where his packages box is, and put this in the box").

Hmm, okay, there's something slightly different with closures. But
it's still unambiguous at compile time.

>>> x=1
>>> def foo(y):
	return lambda z: x+y+z

>>> foo(2)(3)
6
>>> import dis
>>> dis.dis(foo(2))
  2           0 LOAD_GLOBAL              0 (x)
              3 LOAD_DEREF               0 (y)
              6 BINARY_ADD
              7 LOAD_FAST                0 (z)
             10 BINARY_ADD
             11 RETURN_VALUE

What multiple namespaces are you talking about, where things have to
get looked up at run time?

ChrisA

[toc] | [prev] | [next] | [standalone]

#27927

On Sun, 26 Aug 2012 23:58:31 +1000, Chris Angelico wrote:

> On Sun, Aug 26, 2012 at 11:43 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> It gets worse: Python has multiple namespaces that are searched.
>>
>> "Go to the Excelsior Hotel and ask the concierge for Mr Smith. If Mr
>> Smith isn't staying there, go across the road to the Windsor Hotel and
>> ask there. If he's not there, try the Waldorf Astoria, and if he's not
>> there, try the Hyperion."
> 
> Does it? I thought the difference between function-scope and
> module-scope was compiled in,

It is. But local and global scope are not the only two scopes. Python has 
nested scopes. Try these:

x = y = -99
def test():
    def inner():
        x = 23
        def even_more_inner():
            print "x is", x
            print "y is", y
        even_more_inner()
    x = 1000
    y = 42
    inner()

Also, built-ins require a name lookup too. As you point out, locals are 
special, but Python will search an arbitrarily deep set of nested 
nonlocal scopes, then globals, then builtins.

See the introduction of nested-scopes:

http://www.python.org/dev/peps/pep-0227/

and non-locals:

http://www.python.org/dev/peps/pep-3104/


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27928

On Mon, Aug 27, 2012 at 12:18 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Also, built-ins require a name lookup too. As you point out, locals are
> special, but Python will search an arbitrarily deep set of nested
> nonlocal scopes, then globals, then builtins.

Ah, builtins, forgot that. So yes, global scope involves potentially
two name lookups. But nonlocals aren't searched at run time.

ChrisA

[toc] | [prev] | [next] | [standalone]

#27951

On Mon, 27 Aug 2012 00:54:05 +1000, Chris Angelico wrote:

> On Mon, Aug 27, 2012 at 12:18 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Also, built-ins require a name lookup too. As you point out, locals are
>> special, but Python will search an arbitrarily deep set of nested
>> nonlocal scopes, then globals, then builtins.
> 
> Ah, builtins, forgot that. So yes, global scope involves potentially two
> name lookups. But nonlocals aren't searched at run time.

Well, whaddyaknow. You're right.

x = 'globals'
def test(switch):
    def a():
        if switch == 1:
            x = 'a'
        def b():
            if switch == 2:
                x = 'b'
            def c():
                print "x found in", x
            c()
        b()
    a()


Tried that in Jython, IronPython and Python 2.7, and I get the same 
result: only test(2) succeeds.

I even tried it in Python 2.2, which does the same thing.

(2.1 and older don't have nested scopes, so there's no point in going 
back further.)


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27924

In article <503a2804$0$6574$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

>>> The mapping of name:address is part of the *compilation* process -- 
>>> the compiler knows that variable 'x' corresponds to location 
>>> 12345678

Just to pick a nit, the compiler probably doesn't know that, but the 
linker does (or maybe even the run-time loader).  However, we can think 
of all of those as just part of the compilation tool chain, and then 
we're good.

[toc] | [prev] | [next] | [standalone]

#27926

On Mon, Aug 27, 2012 at 12:02 AM, Roy Smith <roy@panix.com> wrote:
> In article <503a2804$0$6574$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>>>> The mapping of name:address is part of the *compilation* process --
>>>> the compiler knows that variable 'x' corresponds to location
>>>> 12345678
>
> Just to pick a nit, the compiler probably doesn't know that, but the
> linker does (or maybe even the run-time loader).  However, we can think
> of all of those as just part of the compilation tool chain, and then
> we're good.

Hrm. Back when I first started C programming, it was MS-DOS 16-bit
work - segmented addressing (one of the most fascinating insanities
ever to be perpetrated on unsuspecting consumers - why, oh why, if you
want 20-bit addressing, should you invent a system that uses 32 bits
of data in such a non-expandable way?). My program would be loaded
into whatever segment the loader chose, but offsets within that could
be compiled in.

With modern x86 systems there are several more layers of complication,
but in many cases, you can still hard-code offsets within a logical
segment of memory. Set CS to your one code segment and do your jumps
and calls at fixed locations. Set [DEFG]S to your single data segment
and all your data can be at fixed locations too. (Obviously your stack
is referenced relative to SP/BP.)

I'm not familiar with other architectures, but it seems likely that
there's something similar. The segment / base location may change, but
variable 'x' still corresponds to 12345678 within that.

Nits can be fun to pick :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#27945

On 26 Aug 2012 13:43:33 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:


> 
> (In some older versions of Python, wildcard imports are allowed, and the 
> function then falls back on a namespace instead of fixed locations. That 
> is no longer the case in Python 3.2 at least.)
>
	Must be really old:

PythonWin 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit
(Intel)] on win32.
Portions Copyright 1994-2006 Mark Hammond - see 'Help/About PythonWin'
for further copyright information.
>>> def ham():
... 	from math import *
<interactive input>:1: SyntaxWarning: import * only allowed at module
level
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#27954

On Sun, 26 Aug 2012 16:12:40 -0400, Dennis Lee Bieber wrote:

> On 26 Aug 2012 13:43:33 GMT, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> declaimed the following in
> gmane.comp.python.general:
> 
> 
> 
>> (In some older versions of Python, wildcard imports are allowed, and
>> the function then falls back on a namespace instead of fixed locations.
>> That is no longer the case in Python 3.2 at least.)
>>
> 	Must be really old:

Not really. You get a SyntaxWarning back to at least 2.2, but the 
fallback namespace behaviour does work through to 2.7:

py> assert 'pi' not in globals()
py> def test():
...     from math import *
...     print pi
... 
<stdin>:1: SyntaxWarning: import * only allowed at module level
py> test()
3.14159265359

What I didn't realise until just now is that it's a bit more complicated 
than that. Using import * in a function you can end up with two distinct 
sets of locals, those using numbered memory slots (effectively address-
based), and those using a dict namespace.

If you assign to a name in the function, it still gets turned into a 
memory slot rather than being in a dict. Decompiling the function shows 
that such local are still accessed using LOAD_FAST and STORE_FAST op-
codes. (That's the case all the way back to Python 1.5 at least.)

But if you *don't* assign to the name, Python uses LOAD_NAME instead, 
which searches namespace. In this case pi is not found in the global or 
built-in namespaces, so there must be a local, dict-based namespace in 
addition to the usual LOAD_FAST slots. Hence, two distinct sets of locals.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27905

On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll <driscoll@cs.wisc.edu> wrote:
> Third, and more wackily, you could technically create a C implementation
> that works like Python, where it stores variables (whose addresses aren't
> taken) in a dict keyed by name, and generates code that on a variable access
> looks up the value by accessing that dict using the name of the variable.

That would be a reasonable way to build a C interactive interpreter.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web