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!

[mensanator]

On Oct 1, 10:03?pm, rjcarr <rjc...@gmail.c omwrote:

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'

What do suppose that message means?

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

Because you misspelled it. First, do a dir() on logging:

>>import logging
dir(logging )

['BASIC_FORMAT', 'BufferingForma tter', 'CRITICAL', 'DEBUG', 'ERROR',
'FATAL', 'FileHandler', 'Filter', 'Filterer', 'Formatter', 'Handler',
'INFO', 'LogRecord', 'Logger', 'Manager', 'NOTSET', 'PlaceHolder',
'RootLogger', 'StreamHandler' , 'WARN', 'WARNING', '__author__',
'__builtins__', '__date__', '__doc__', '__file__', '__name__',
'__path__', '__status__', '__version__', '_acquireLock',
'_defaultFormat ter', '_handlerList', '_handlers', '_levelNames',
'_lock', '_loggerClass', '_releaseLock', '_srcfile', '_startTime',
'addLevelName', 'atexit', 'basicConfig', 'cStringIO', 'codecs',
'critical', 'currentframe', 'debug', 'disable', 'error', 'exception',
'fatal', 'getLevelName', 'getLogger', 'getLoggerClass ', 'info', 'log',
'logProcesses', 'logThreads', 'makeLogRecord' , 'os',
'raiseException s', 'root', 'setLoggerClass ', 'shutdown', 'string',
'sys', 'thread', 'threading', 'time', 'traceback', 'types', 'warn',
'warning']

You can now pick any item from this list to further expand
with dir(), but notice "handlers" isn't one of them.

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!

[Robert Kern]

me********@aol. com wrote:

On Oct 1, 10:03?pm, rjcarr <rjc...@gmail.c omwrote:

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

What do suppose that message means?

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

Because you misspelled it. First, do a dir() on logging:

No, he didn't. There is a logging.handler s module; it's just not imported by
importing logging.

OP: logging is a package and logging.handler s is one module in the package. Not
all of the modules in a package are imported by importing the top-level package.
os.path is a particularly weird case because it is just an alias to the
platform-specific path-handling module; os is not 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

[Lawrence D'Oliveiro]

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

Not all of the modules in a package are imported by importing the
top-level package.

You can't import packages, only modules.

os.path is a particularly weird case because it is just an alias to the
platform-specific path-handling module; os is not a package.

os is a module, os.path is a variable within that module. That's all there
is to it.

[Marc 'BlackJack' Rintsch]

On Tue, 02 Oct 2007 19:34:29 +1300, Lawrence D'Oliveiro wrote:

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

>Not all of the modules in a package are imported by importing the
top-level package.

You can't import packages, only modules.

Oh come on, this is unnecessary nitpicking. Importing the module
`__init__` from a package using the name of the package is close enough to
justify the phrase "I import the package" IMHO.

Ciao,
Marc 'BlackJack' Rintsch

[Robert Kern]

Lawrence D'Oliveiro wrote:

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

>Not all of the modules in a package are imported by importing the
top-level package.

You can't import packages, only modules.

>os.path is a particularly weird case because it is just an alias to the
platform-specific path-handling module; os is not a package.

os is a module, os.path is a variable within that module. That's all there
is to it.

Yes, but os.path is also module. That's why I said it was a weird case.

In [1]: import os

In [2]: type(os.path)
Out[2]: <type 'module'>

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

[Lawrence D'Oliveiro]

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

Lawrence D'Oliveiro wrote:

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

>>Not all of the modules in a package are imported by importing the
top-level package.

You can't import packages, only modules.

>>os.path is a particularly weird case because it is just an alias to the
platform-specific path-handling module; os is not a package.

os is a module, os.path is a variable within that module. That's all
there is to it.

Yes, but os.path is also module. That's why I said it was a weird case.

You can't have modules within modules. os.path isn't an exception--see
below.

In [1]: import os

In [2]: type(os.path)
Out[2]: <type 'module'>

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.

[Lawrence D'Oliveiro]

In message <ma************ *************** ***********@pyt hon.org>, Steve
Holden wrote:

You *can* import a package ...

You're right. I was misremembering the behaviour of PyCrypto, where
importing the upper-level packages do little more than give you a list of
what algorithms are available.

[Ben Finney]

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

--
\ "Crime is contagious ... if the government becomes a |
`\ lawbreaker, it breeds contempt for the law." -- Justice Louis |
_o__) Brandeis |
Ben Finney

[Bruno Desthuilliers]

Lawrence D'Oliveiro a écrit :

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

>Lawrence D'Oliveiro wrote:

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

Not all of the modules in a package are imported by importing the
top-level package.
You can't import packages, only modules.

os.path is a particularly weird case because it is just an alias to the
platform-specific path-handling module; os is not a package.
os is a module, os.path is a variable within that module. That's all
there is to it.

Yes, but os.path is also module. That's why I said it was a weird case.

You can't have modules within modules.

If you're talking about the filesystem representation (ie : .py files),
you obviously can't have a file within a file, indeed.

When it comes to the internal runtime representation of modules in
Python, then it's totally different - a module is just an object, that
can of course be an attribute of another module object.

>>import os
type(os)

<type 'module'>

>>type(os.pat h)

<type 'module'>

>>>

os.path isn't an exception--see
below.

>In [1]: import os

In [2]: type(os.path)
Out[2]: <type 'module'>

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.

It's just a name bound to a module object.