module confusion

[Steve Holden]

Yes. That's exactly why it's wrong to refer to them as pointers. They
don't behave like the pointers in other languages, which are *not*
"automatically-dereferenced", nor "to objects of arbitrary type".

It's misleading to talk about a Python name as a "pointer" without
those qualifiers, because they're *not* implicit in programmers'
understanding of that term.

If you want to continually refer to them as
"automatically-dereferenced pointers to objects of arbitrary type", by
all means go ahead. That at least *does* fit the semantics. But the
simple term "pointer" does *not* describe them in the absence of those
necessary and non-default qualifiers, and is misleading.

In practice I am quite happy talking about "variables" as long as nobody
is picking nits, but I am afraid that in this thread the nits are not
only being picked, they are being boiled alive and eaten.

Consequently I feel obliged to reply in my own defense that if you
weren't intelligent enough to recognize that description as essentially
correct this conversation need have gone no further. I don't encourage
people to talk in terms of pointers most of the time, but I find that
such pedagogic devices are useful in discussing the essential
differences between mutable and immutable values.

Neither do I normally attempt to mislead (as an examination of my record
on this group should confirm), which is precisely why the qualifiers
*were* attached. So kindly do not tell me it's "wrong" to refer them as
pointers. Such phraseology can tend to be emotionally charged (for
instance when proponents have religious feelings about their beliefs).

Fortunately programming languages and operating systems have never been
religious issues for me. It's more like "This problem has a cross head,
so I'll need a Philips screwdriver". I don't worship my spirit level, so
I'm damned if I will worship LISP or Python. They can both be *jolly*
useful, though

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

 

[Lawrence D'Oliveiro]

No. "os.path" refers to the object that's known as the "path" attribute
of the object known as "os". That object, in turn, is a module.

No, it's a variable. It just happens to contain a pointer to a module.

While it is true that namespaces are implemented in CPython as
collections of pointers to PyObject structures, that's an irrelevant
implementation detail. I doubt that they are implemented as pointers in
Jython, PyPy, or IronPython.

I'll bet they are.

No, it doesn't. A pointer means the physical address of a memory
location, which implies that you can overwrite that memory location. Can
you do that in Python?

Yes. Look up the definition of "mutable objects".

 

[Hendrik van Rooyen]

Honestly, why do people react to the word "pointer" as though computers have
to wear underwear to conceal something shameful going on in their nether
regions?

I think it is because a pointer is a variable containing as a value the address
of something.

So its a low level concept - useful to low-lifes like C and assembler
programmers, and as
such, capable of causing extreme mayhem in your nicely structured, high level
life.

So it boils down to fear - also known as: "once bitten, twice shy"

- Hendrik

 

[Hendrik van Rooyen]

religious issues for me. It's more like "This problem has a cross head,
so I'll need a Philips screwdriver".

As long as it is not a Pozidrive, that is a commendable attitude.

- Hendrik

 

[Steven D'Aprano]

In Python, all names _are_ variables. They are not "bound" to objects.

The general convention among Python programmers is to describe names
being bound to values. While the analogy to real life binding of objects,
it's close enough to be useful.

The value of os.path is a pointer. It's implemented as a pointer, it has
all the semantics of a pointer.

Ah, I see you are a devotee of Humpty Dumpty:

"When I use a word," Humpty Dumpty said, in rather
a scornful tone, "it means just what I choose it to
mean-neither more nor less."

"The question is," said Alice, "whether you can
make words mean so many different things."

"The question is," said Humpty Dumpty, "which is to
be master -- that's all."


The rest of the world understands pointers to be in the sense of pointers
in C, Pascal and similar: a low level construct that is to all extents
and purposes a memory location whose content is itself a memory location.

Oh sure, I suppose there are a few pedants who insist that "pointer" just
means "something which points to something else". There may even be a
language or two whose users regularly use the term "pointer" to mean
something other than the common usage, and may never have been exposed to
the common usage.

And thus, satisfied in their own mind that *technically* they're right,
or at least not provably wrong, the pedants insist on calling Python
names "pointers" regardless of the confusion it confuses to the majority
of programmers and despite the violence they have to do to the human
language for it to work.

Of course, we can *easily* find out what the type of os.path is. Python
allows us to interrogate any object and find out its type:
<type 'module'>

It's a module, not a pointer. End of story.

Honestly, why do people react to the word "pointer" as though computers
have to wear underwear to conceal something shameful going on in their
nether regions?

The real question is why people insist on hammering the square peg of C
terminology into the round holes of Python's object model.

 

[Lawrence D'Oliveiro]

... pedants ...

When people use that word against me, it's generally a sign they're trying
not to admit I'm right.

 

[Steve Holden]

As long as it is not a Pozidrive, that is a commendable attitude.

I said cross head, not Pozidriv (tm). But then I have been nown to use a
Manchester screwdriver[1] on occasion.

regards
Steve

[1]: http://www.urbandictionary.com/define.php?term=manchester+screwdriver
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

 

[Steve Holden]

When people use that word against me, it's generally a sign they're trying
not to admit I'm right.

If it were less important to be right and more important to be
considerate this thread could end without a further contribution from
you ...

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline so I couldn't cat it

 

[Bruno Desthuilliers]

Lawrence D'Oliveiro a écrit :

No, it's a variable. It just happens to contain a pointer to a module.

Lawrence, you should have a look at CPython's source code. And at other
implementations too. Python's "variables" *really* are name/object pairs
- most of the time key/value pairs in a dict. The name itself is just
that : a name. It doesn't "contains" anything, it's *not* a label for a
memory address, it's *only* a name.

I'll bet they are.

Since Java doesn't have pointers, you lost your bet.

Yes. Look up the definition of "mutable objects".

I think Carsten knows this definition. But it has nothing to do with
"overwriting a memory location" - like you could do in C using pointers.

 

[Neil Cerutti]

In Python, all names _are_ variables. They are not "bound" to
objects. The value of os.path is a pointer. It's implemented as
a pointer, it has all the semantics of a pointer.

No. A pointer is also an iterator.

void duplicate(char *d, const char *s)
{
while (*d++ = *s++)
;
}

What does that look like implemented with Python names?

def duplicate(d, s):
raise AbstractionViolationError("Python identifiers aren't pointers.")

Moreover, it seems difficult to promote the concept of a pointers
in a language which doesn't provide a "take the address of an
object" operation.

Honestly, why do people react to the word "pointer" as though
computers have to wear underwear to conceal something shameful
going on in their nether regions?

Refraining from thinking about pointers (unless I have to) saves
wear and tear on the old bean. I also like to think of 5 as an
integer most of the time.

 

[Steven D'Aprano]

When people use that word against me, it's generally a sign they're
trying not to admit I'm right.

Yeah, you keep telling yourself that.

What does type(os.path) return when you try it?

 

[MRAB]

"Steve Holden" <ste...web.com> wrote:

As long as it is not a Pozidrive, that is a commendable attitude.

I said cross head, not Pozidriv (tm). But then I have been nown to use a
Manchester screwdriver[1] on occasion.

regards
Steve

[1]:http://www.urbandictionary.com/define.php?term=manchester+screwdriver

It's also called a Brummie screwdriver:

http://en.wikipedia.org/wiki/Brummie

 

[Lawrence D'Oliveiro]

What does type(os.path) return when you try it?

It returns the type of the value contained in that variable, of course:
<type 'int'>

See, it's just a variable, like any other.

 

[Lawrence D'Oliveiro]

No. A pointer is also an iterator.

void duplicate(char *d, const char *s)
{
while (*d++ = *s++)
;
}

So if you can't do pointer arithmetic, then it's not a pointer? Trying this:

void duplicate(void *d, const void *s)
{
while (*d++ = *s++)
;
}

I get:

test.c: In function 'duplicate':
test.c:3: warning: dereferencing 'void *' pointer
test.c:3: warning: dereferencing 'void *' pointer
test.c:3: error: invalid use of void expression

So you can't do arithmetic or iterate with a void * pointer. Does that mean
it's not really a pointer?

 

[Robert Kern]

It returns the type of the value contained in that variable, of course:

<type 'int'>

See, it's just a variable, like any other.

Oooookay. No one is contending that the "os.path" name can't be reassigned to a
different object or that the "os.path" name is somehow different from any other
name in Python. It's not wrong to say that "os is a module" either, even though
you can obviously reassign that name to another object, too.

What I meant when I said "os.path is a bit of a weird case" is that, by default,
the object referred to by the name "os.path" (assuming you've imported the
standard library's os module) is another module and that os itself is a module,
not a package like logging is. This is somewhat odd, because most modules aren't
exposed that way. They are either in their own file and accessed by importing
them directly, or they are inside a package.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Hendrik van Rooyen]

As long as it is not a Pozidrive, that is a commendable attitude.

I said cross head, not Pozidriv (tm). But then I have been nown to use a
Manchester screwdriver[1] on occasion.

Philistine!

But in a way, it is more honest than the Free State method of tightening a bolt-

You tighten enthusiastically until it strips, then go a quarter turn back to
undo
the damage.

BTW, in case you have been wondering - a Free State Micrometer is a
plumber's adjustable pipe wrench.

- Hendrik

 

[Lawrence D'Oliveiro]

Oooookay. No one is contending that the "os.path" name can't be reassigned
to a different object or that the "os.path" name is somehow different from
any other name in Python. It's not wrong to say that "os is a module"
either, even though you can obviously reassign that name to another
object, too.

It is not the _name_ that is being reassigned, it is the _variable_ that the
name is bound to. All names in Python are bound to variables at all times.

What I meant when I said "os.path is a bit of a weird case" is that, by
default, the object referred to by the name "os.path" (assuming you've
imported the standard library's os module) is another module and that os
itself is a module, not a package like logging is. This is somewhat odd,
because most modules aren't exposed that way. They are either in their own
file and accessed by importing them directly, or they are inside a
package.

That is also true of the module pointed to by os.path. Like any other
non-built-in module, it lives in its own file.

It also helps to keep clear the difference between a "module" and a "module
object". A "module" is the contents of a Python source file, while
a "module object" is a type of in-memory Python object. An "import"
statement generates the latter from the former. See
<http://docs.python.org/ref/types.html>. Admittedly, other parts of the
Python docs do not keep the distinction clear, but the section on "Modules"
in that page does just about do so.

You can't have modules within modules. But there's no reason an attribute of
one module object can't point to another module object. Notice I say "point
to" rather than "contain". There is no sense in which any Python object
can "contain" any other.

 

[Bruno Desthuilliers]

Lawrence D'Oliveiro a écrit :

It returns the type of the value contained in that variable, of course:

Certainly not. You're confusing Python with C. In Python, 'variables'
are *not* labels for memory locations containing values. Period

<type 'int'>

See, it's just a variable, like any other.

This is bad faith.
<type 'module'>

See, this is a name bound to an object, like any other.

 

[Marc 'BlackJack' Rintsch]

It is not the _name_ that is being reassigned, it is the _variable_ that
the name is bound to. All names in Python are bound to variables at all
times.

I think this is the source of the confusion. Most people don't seem
to share your definition of `variable` above.

To me a `variable` is made of a name, a memory address, a data type, and
a value. In languages like C the address and type are attached to the
name while in Python both are attached to the value.

Ciao,
Marc 'BlackJack' Rintsch

 

[Steven D'Aprano]

There is no sense in which any Python object can "contain" any other.

L = [1, 2, 3]
2 in L True
L.__contains__(3)

True