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!

[Lawrence D'Oliveiro]

In message <ma************ *************** ***********@pyt hon.org>, Robert
Kern wrote:

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.

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 :

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:

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

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

<type 'int'>

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

This is bad faith.

>>import os
type(os.pat h)

<type 'module'>

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

[Marc 'BlackJack' Rintsch]

On Fri, 05 Oct 2007 19:51:05 +1300, Lawrence D'Oliveiro wrote:

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]

On Fri, 05 Oct 2007 19:51:05 +1300, Lawrence D'Oliveiro wrote:

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

--
Steven.

[Steven D'Aprano]

On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:

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.

Any time you say:

import parrot
in one of your modules, you export parrot to anything that imports your
module. (Unless you take specific steps to prevent it, for instance with
del parrot.)
Just to pick some random examples:

>>import ConfigParser, base64, fileinput
ConfigParser. re

<module 're' from '/usr/lib/python2.5/re.pyc'>

>>base64.stru ct

<module 'struct' from '/usr/lib/python2.5/struct.pyc'>

>>base64.binasc ii

<module 'binascii' from '/usr/lib/python2.5/lib-dynload/binascii.so'>

>>fileinput.s ys

<module 'sys' (built-in)>

>>fileinput.o s

<module 'os' from '/usr/lib/python2.5/os.pyc'>
It's quite common.
--
Steven.

[Steve Holden]

Steven D'Aprano wrote:

On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:

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

Any time you say:

import parrot
in one of your modules, you export parrot to anything that

subsequently

imports your
module. (Unless you take specific steps to prevent it, for instance with
del parrot.)

or the creation of an __all__ containing an exclusive list of names for
export.

>

Just to pick some random examples:

>>>import ConfigParser, base64, fileinput
ConfigParser .re

<module 're' from '/usr/lib/python2.5/re.pyc'>

>>>base64.struc t

<module 'struct' from '/usr/lib/python2.5/struct.pyc'>

>>>base64.binas cii

<module 'binascii' from '/usr/lib/python2.5/lib-dynload/binascii.so'>

>>>fileinput.sy s

<module 'sys' (built-in)>

>>>fileinput. os

<module 'os' from '/usr/lib/python2.5/os.pyc'>
It's quite common.

OK, I am sort of getting used to the idea that you guys are going to
beat this one to death with a stick, and will still be tossing emails
back and forth to each other while the rest of us are admiring the heat
death of the universe.

So please try and avoid writing anything that will be misconstrued by
newless cloobs unfortunate enough to reach this thread as a result of a
search for meaningful information on Python imports.

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

[Neil Cerutti]

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

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

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

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

....or dereference.

Does that mean it's not really a pointer?

That's an interesting taxonimical conundrum. If a pointer were
defined by it's semantics, then yes, a void pointer wouldn't be a
pointer. But pointers are defined not by behavior, but by an
ANSI/ISO standard. The term "pointer to void" makes sense if you
think of it as a pointer in an altered, intermediate state.

I suppose you might score a Pyrrhic victory by claiming that
Python identifiers are pointers that don't behave like pointers.
But you claimed the opposite.

--
Neil Cerutti

[Steven D'Aprano]

On Fri, 05 Oct 2007 07:37:34 -0400, Steve Holden wrote:

Steven D'Aprano wrote:

>On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:

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

Any time you say:

import parrot
in one of your modules, you export parrot to anything that

subsequently

Well obviously you have to write the module before people import it. I
didn't really think "you must obey the laws of time and space" needed to
be explained.

>imports your
module. (Unless you take specific steps to prevent it, for instance
with del parrot.)

or the creation of an __all__ containing an exclusive list of names for
export.

No.

__all__ only effects names imported with "from module import *", it has
no effect on "import module".

What was that again about avoiding "writing anything that will be
misconstrued by newless cloobs unfortunate enough to reach this thread as
a result of a search for meaningful information on Python imports"?

--
Steven.

[Steve Holden]

Steven D'Aprano wrote:

On Fri, 05 Oct 2007 07:37:34 -0400, Steve Holden wrote:

>Steven D'Aprano wrote:

>>On Fri, 05 Oct 2007 00:12:33 -0500, Robert Kern wrote:

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.
Any time you say:

import parrot
in one of your modules, you export parrot to anything that

subsequently

Well obviously you have to write the module before people import it. I
didn't really think "you must obey the laws of time and space" needed to
be explained.

But a module needn't be fully executed before it's imported.

>

>>imports your
module. (Unless you take specific steps to prevent it, for instance
with del parrot.)

or the creation of an __all__ containing an exclusive list of names for
export.

No.

__all__ only effects names imported with "from module import *", it has
no effect on "import module".

What was that again about avoiding "writing anything that will be
misconstrued by newless cloobs unfortunate enough to reach this thread as
a result of a search for meaningful information on Python imports"?

Well, precisely.

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

[Lawrence D'Oliveiro]

In message <5m************ @mid.uni-berlin.de>, Marc 'BlackJack' Rintsch
wrote:

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.

How does C++ with RTTI fit into your picture, then?