Re: Python internals

[Larry Bates]

Peter Anderson wrote:

Hi! I am slowly teaching myself Python. I was reading David Beazley's
excellent book "Python - Essential Reference"; in particular about
variables. Let me quote:
>
"Python is a dynamically typed language in which names can represent
values of different types during the execution of a program. In fact the
names used in the program are really just labels for various quantities
and objects. The assignment operator simply creates an association
between a name and a value. This is different from C, for example, in
which a name (variable) represents a fixed size and location in memory..."
>
As an old mainframe programmer, I understand the way C does things with
variable but this text got me wondering how Python handles this
"associatio n" between variable name and value at the lower level. Is it
like a fifo list?
>
If there is any Python guru that can help I would be most interested in
your thoughts.
>
Regards,
Peter

Names are pointers in Python that point to values in memory. Names are "bound"
to these values with assignment. Names are NOT buckets where you put values as
is the case (or thought process) in other languages. Example:

a = list(1,2,3)
b = a

Now a AND b point to the same list in memory

Note: if you wanted a COPY of the list you should do:

b = a[:]

Names can also point to functions, class instances, class methods or any other
object. Example:

def foo(arg):
print arg


bar = foo

Now you can call bar(arg) or foo(arg) and it will do exactly the same thing.

If you ever wrote assembler than you will begin to understand. varibles are
pointers to objects, not buckets were stuff is stored.

Hope this helps some.

-Larry

[Jan Claeys]

Re: Python internals

Op Tue, 15 Jul 2008 09:29:58 -0500, schreef Larry Bates:

Names are pointers in Python that point to values in memory.

But "pointers" doesn't have the same meaning as in "C" here.

Memory in Python is not (necessarily) an "array of bytes"; how & where
the values are stored in "physical memory" at any time during the
lifetime of an object is an implementation detail.

Maybe you can compare it to how a (university) library works: you ask a
librarian for a book named "The Taste Of Man by Slavenka Draculić" and
they fetch it for you, using whatever internal classification/retrieval
system they use.


--
JanC

[Ben Finney]

Re: Python internals

Larry Bates <larry.bates@we bsafe.com`write s:

Names are pointers in Python that point to values in memory.

The term "pointer" carries much extra baggage for a programmer
thinking of C (as the original poster is). Python names give no access
to the "address" of the value, and don't need to be "de-referenced".

I've had better success explaining Python names to such people in
terms of "references ": there is no "address" and no "de-reference"
needed. Access the name, and you get its value.

On the other hand, I prefer to avoid using either of those concepts,
and talk in terms of "name tags" or "sticky notes". Names (and other
references, like list elements) attach to the object, and have no
other value or purpose. They don't affect the object they're attached
to; they are entirely independent of other bindings to the same
object; they re-bind to another object with no history of what they
were bound to previously.

The analogy is quite robust, and carries none of the confusing baggage
of "variable" or "pointer" or other overloaded language terms.

--
\ “Are you pondering what I'm pondering?” “I think so, Brain, but |
`\ I don't think Kay Ballard's in the union.” —_Pinky and The |
_o__) Brain_ |
Ben Finney

[Larry Bates]

Re: Python internals

Ben Finney wrote:

Larry Bates <larry.bates@we bsafe.com`write s:
>

>Names are pointers in Python that point to values in memory.

>
The term "pointer" carries much extra baggage for a programmer
thinking of C (as the original poster is). Python names give no access
to the "address" of the value, and don't need to be "de-referenced".
>
I've had better success explaining Python names to such people in
terms of "references ": there is no "address" and no "de-reference"
needed. Access the name, and you get its value.
>
On the other hand, I prefer to avoid using either of those concepts,
and talk in terms of "name tags" or "sticky notes". Names (and other
references, like list elements) attach to the object, and have no
other value or purpose. They don't affect the object they're attached
to; they are entirely independent of other bindings to the same
object; they re-bind to another object with no history of what they
were bound to previously.
>
The analogy is quite robust, and carries none of the confusing baggage
of "variable" or "pointer" or other overloaded language terms.
>

You are, of course, correct. Since I'm not a C programmer, the term pointer
doesn't carry the same "baggage" as it might to others. The "problem" I had
when I first started is that people were using such "vague" terms like names,
tags, etc. that it had no meaning to me. I like your idea of "references ".

-Larry

[Ben Finney]

Re: Python internals

Peter Anderson <peter.anderson @internode.on.n etwrites:

If Python doesn't do it like C and the others then what mechanism does
it use

You've already been pointed to it, but here it is again:
<URL:http://effbot.org/zone/python-objects.htm>

--
\ “I may disagree with what you say, but I will defend to the |
`\ death your right to mis-attribute this quote to Voltaire.” |
_o__) —Avram Grumer, rec.arts.sf.wri tten, May 2000 |
Ben Finney

[Scott David Daniels]

Re: Python internals

Peter Anderson wrote:

Thanks everyone! Just a quick correction - "as the original poster is"
is a bit of a jump that does not reflect my original question. I DO
understand how C and other programming languages handle variables
internally (the bits of actual memory reserved, etc. etc.) and that's
why I asked the question in the first place.
>
If Python doesn't do it like C and the others then what mechanism does
it use - it's the sort of issue that helps me understand how the
language is interacting with the underlying operating system/hardware.

The easiest way to think of this is that Python uses mostly dictionaries
dictionaries for namespaces, and a few places it uses other techniques
if there are over-riding considerations that make the dictionaries
impractical in particular cases. Python performance would be crippled
if their dictionary implementation( s) slowed down, much as C performance
would suffer is access to RAM slowed down.

--Scott David Daniels
Scott.Daniels@A cm.Org