module confusion

[rjcarr]

Sorry if this is a completely newbie question ...

I was trying to get information about the logging.handlers module, so
I imported logging, and tried dir(logging.handlers), 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]

Sorry if this is a completely newbie question ...

I was trying to get information about the logging.handlers module, so
I imported logging, and tried dir(logging.handlers), 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:
['BASIC_FORMAT', 'BufferingFormatter', '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',
'_defaultFormatter', '_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',
'raiseExceptions', '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.

 

[Robert Kern]

What do suppose that message means?


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

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

OP: logging is a package and logging.handlers 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]

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]

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]

You can't import packages, only modules.


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

 

[Steve Holden]

You can't import packages, only modules.


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

The Python documentation could probably be a little more expansive on
the import front, but it's an area where historically many different
attempts have been made to fix up the problems, or create new and more
usable layers [that suffer from different problems].

You *can* import a package, and a package is just a *little* different
from a module in that the __init__.py file in the package directory
provides the source for the first-import execution instead of the
modulename.py file. The global namespace during this process is the
package's global namespace, so if further imports are executed by the
__init__ module the names of the imported objects are created in the
package global namespace (along with the names of defined classes and
functions, and other names bound by assignment) and can therefore be
referenced relative to it. The package in which the package import was
executed will end up defined in the namespace in which the import
statement was executed.

I will grant that you can't basically do anything in the __init__.py
that you can't do in a module's modulename.py file. It is possible to
define a hierarchy of namespaces concordant with the package's directory
structure, but it doesn't matter whether package import creates the
hierarchical namespace or assignment does. You can access module
namespaces in a hierarchical way.

That's about all that can be said without delving into the murky land of
relative vs. absolute imports. That can be for another day. And another
writer, probably.

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

 

[Lawrence D'Oliveiro]

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

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

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]

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

 

[Bruno Desthuilliers]

Lawrence D'Oliveiro a écrit :

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.

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

In [1]: import os

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

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.

 

[Gabriel Genellina]

En Wed, 03 Oct 2007 07:12:17 -0300, Lawrence D'Oliveiro

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

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.

A "module" is a certain type of Python objects, like ints, functions,
exceptions and all else.
The easiest way to create a module is to load it from file, but some
modules are already built into the interpreter, and you can even create a
module from scratch.

py> import os
py> type(os)
<type 'module'>
py> type(os.path)
<type 'module'>
py> os
<module 'os' from 'c:\apps\python25\lib\os.pyc'>
py> import sys
py> type(sys)
<type 'module'>
py> sys
<module 'sys' (built-in)>
py> ModuleType = type(os)
py> newmodule = ModuleType('newmodule')
py> newmodule.a = 3
py> newmodule
<module 'newmodule' (built-in)>
py> type(newmodule) is type(os.path)
True

"os" is a name that refers to the os module object. "os.path" means "the
path attribute in the object referenced by the name os", that happens to
be another module too.
os is not a package; os.path is set when the os module is imported,
depending on the platform. It may be ntpath, posixpath, macpath, or
whatever. On Windows:

py> import ntpath
py> os.path is ntpath
True
py> import macpath
py> import posixpath
py> macpath.sep
':'
py> ntpath.sep
'\\'

Apart from that, there is no magic involved, just plain attribute access
like everywhere else.

 

[Carsten Haese]

Sorry for the wrong title of this email. Please ignore this email. I
have resend the question with correct title.

But it's still in the wrong thread. When asking a new question, you
should compose a new message instead of replying to an existing message.

 

[Robert Kern]

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

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.

I believe that is precisely what I was saying.

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

 

[Michael Spencer]

+1 Subject line of the week (SLOTW)

So my question is ... why are they [os.path and logging.handlers] different?

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

No, he didn't... OP: logging is a package and logging.handlers is one module
in the package... os.path is a particularly weird case...

You can't import packages, only modules.

Oh come on, this is unnecessary nitpicking.

> You *can* import a package, and a package is just a *little* different from a
> module

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

a module is just an object, that can of course be an attribute of another
module object

os is not a package; os.path is set when the os module is imported

You're right. I was misremembering the behaviour of PyCrypto

In Matlab you can use function dec2bin, hex2dec, dec2hex bin2dec functions to
convert decimal to binary and heximal etc.

I believe that is precisely what I was saying.

with apologies to all concerned

Michael

 

[Lawrence D'Oliveiro]

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.

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?

 

[Carsten Haese]

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.

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
implementation detail. I doubt that they are implemented as pointers in
Jython, PyPy, or IronPython.

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?

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 won't speak for "people", but maybe it's because Python acts precisely
as this underwear that does conceal the low-level regions of memory
management and bit-twiddling that Python programmers like to avoid in
favor of solving higher-level problems.

If it helps you to think of Python names as "kind of like pointers,"
you're free to do so, but it's only a weak analogy that can lead
beginners to drawing incorrect conclusions.

 

[Steve Holden]

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.

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?

Because they have been told by their church that all God-fearing names
do what names have always done in programming languages, which is to
describe areas of memory of a particular size, type and locality.

You and I know that the semantics of Python names are precisely those of
(to use an Algol 68 term, unless I am mistaken) automatically
dereferenced pointers to objects of arbitrary type. I actually think
that's one of the neatest things about Python, and I believe it's no
accident that both Tim Peters and I were Icon enthusiasts.

But the rest of the world clings to its illusions.

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

 

[Steve Holden]

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.

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?

Because they have been told by their church that all God-fearing names
do what names have always done in programming languages, which is to
describe areas of memory of a particular size, type and locality.

You and I know that the semantics of Python names are precisely those of
(to use an Algol 68 term, unless I am mistaken) automatically
dereferenced pointers to objects of arbitrary type. I actually think
that's one of the neatest things about Python, and I believe it's no
accident that both Tim Peters and I were Icon enthusiasts.

But the rest of the world clings to its illusions.

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

 

[Ben Finney]

You and I know that the semantics of Python names are precisely
those of (to use an Algol 68 term, unless I am mistaken)
automatically dereferenced pointers to objects of arbitrary type.

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.