module confusion

[rjcarr]

Sorry if this is a completely newbie question ...

I was trying to get information about the logging.handler s module, so
I imported logging, and tried dir(logging.han dlers), but got:

AttributeError: 'module' object has no attribute 'handlers'

The only experience I have in modules is os and os.path ... if I do
the same thing, simply import os and then type dir(os.path), it
displays the contents as expected.

So my question is ... why are they different? I mean, in terms of
designing these modules, how would you go about getting a sub-module
in your name space? And on the other side, how would you go about
getting it out?

Thanks!

[Hendrik van Rooyen]

"Lawrence D'Oliveiro" <ldo@ge...ew_ze alandwote:

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

[Steven D'Aprano]

On Thu, 04 Oct 2007 11:11:03 +1300, Lawrence D'Oliveiro wrote:

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:

>>import os
type(os.pat h)

<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.

--
Steven.

[Lawrence D'Oliveiro]

In message <13************ *@corp.supernew s.com>, Steven D'Aprano wrote:

... pedants ...

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

[Steve Holden]

Lawrence D'Oliveiro wrote:

In message <13************ *@corp.supernew s.com>, Steven D'Aprano wrote:

>... pedants ...

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 [phone] [phone]
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 :

In message <ma************ *************** ***********@pyt hon.org>, Carsten
Haese wrote:

>On Thu, 2007-10-04 at 11:11 +1300, Lawrence D'Oliveiro wrote:

>>In Python, all names _are_ variables. They are not "bound" to objects.
The value of os.path is a pointer.

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.

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.

>> It's implemented as a pointer,

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

I'll bet they are.

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

>> it has all the semantics of a pointer.

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".

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

[Neil Cerutti]

On 2007-10-03, Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealandwrote:

In message <87************ @benfinney.id.a u>, Ben Finney wrote:

>Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealandwrites:

>>On my Gentoo system:

>>import os
>>os.path
<module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>

It's just a variable that happens to point to the posixpath module.

There's no "pointing" going on. It's another name bound to the
same object, of equal status to the 'posixpath' name.

Python doesn't have pointers, and even "variable" is a
misleading term in Python. Best to stick to "name" and "bound
to".

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 AbstractionViol ationError("Pyt hon 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.

--
Neil Cerutti
Will the last person to leave please see that the perpetual light is
extinguished --sign at New England church

[Steven D'Aprano]

On Thu, 04 Oct 2007 23:01:06 +1300, Lawrence D'Oliveiro wrote:

In message <13************ *@corp.supernew s.com>, Steven D'Aprano wrote:

>... pedants ...

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?

--
Steven.

[Lawrence D'Oliveiro]

In message <13************ *@corp.supernew s.com>, Steven D'Aprano wrote:

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

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

>>import os
os.path = 3
type(os.pat h)

<type 'int'>

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

[Lawrence D'Oliveiro]

In message <sl************ ********@FIAD06 .norwich.edu>, Neil Cerutti wrote:

On 2007-10-03, Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealand>
wrote:

>In message <87************ @benfinney.id.a u>, Ben Finney wrote:

>>Lawrence D'Oliveiro <ld*@geek-central.gen.new _zealandwrites:

On my Gentoo system:

>>import os
>>os.path
<module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>

It's just a variable that happens to point to the posixpath module.

There's no "pointing" going on. It's another name bound to the
same object, of equal status to the 'posixpath' name.

Python doesn't have pointers, and even "variable" is a
misleading term in Python. Best to stick to "name" and "bound
to".

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++)
;
}

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]

Lawrence D'Oliveiro wrote:

In message <13************ *@corp.supernew s.com>, Steven D'Aprano wrote:

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

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

>>import os
>>os.path = 3
>>type(os.pat h)

<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