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]

On Oct 1, 10:03?pm, rjcarr <[e-mail]:

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:

>>import logging
dir(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.

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 <[e-mail]:

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

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]

In message <ma**************************************@python.o rg>, 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**************************************@python.o rg>, 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**************************************@python.o rg>, 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**************************************@python.o rg>, Robert
Kern wrote:

Lawrence D'Oliveiro wrote:

>In message <ma**************************************@python.o rg>, 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**************************************@python.o rg>, 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**************************************@python.o rg>, Robert
Kern wrote:

>Lawrence D'Oliveiro wrote:

>>In message <ma**************************************@python.o rg>, 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.path)

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

[Gabriel Genellina]

En Wed, 03 Oct 2007 07:12:17 -0300, Lawrence D'Oliveiro
<ld*@geek-central.gen.new_zealandescribi�:

In message <ma**************************************@python.o rg>, Robert
Kern wrote:

>Lawrence D'Oliveiro wrote:

>>In message <ma**************************************@python.o rg>,
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.

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.

pyimport os
pytype(os)
<type 'module'>
pytype(os.path)
<type 'module'>
pyos
<module 'os' from 'c:\apps\python25\lib\os.pyc'>
pyimport sys
pytype(sys)
<type 'module'>
pysys
<module 'sys' (built-in)>
pyModuleType = type(os)
pynewmodule = ModuleType('newmodule')
pynewmodule.a = 3
pynewmodule
<module 'newmodule' (built-in)>
pytype(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:

pyimport ntpath
pyos.path is ntpath
True
pyimport macpath
pyimport posixpath
pymacpath.sep
':'
pyntpath.sep
'\\'

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

--
Gabriel Genellina

[Robert Kern]

Lawrence D'Oliveiro wrote:

In message <ma**************************************@python.o rg>, Robert
Kern wrote:

>Lawrence D'Oliveiro wrote:

>>In message <ma**************************************@python.o rg>, 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.

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)

rjcarr wrote:

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

[A] wrote:

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

[b] wrote:

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

[C] wrote:

You can't import packages, only modules.

[D] wrote:

Oh come on, this is unnecessary nitpicking.

[E] wrote:

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

[b] wrote:

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

[C] wrote:

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.

[F] wrote:

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

[G] wrote:

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

[H] wrote:

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

[C] wrote:

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

[J] wrote:

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

[b] wrote:

I believe that is precisely what I was saying.

with apologies to all concerned :-)

Michael

[Lawrence D'Oliveiro]

In message <87************@benfinney.id.au>, 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.

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]

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.

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.

--
Carsten Haese
http://informixdb.sourceforge.net

[Steve Holden]

Lawrence D'Oliveiro wrote:

In message <87************@benfinney.id.au>, 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.

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 [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

[Steve Holden]

Lawrence D'Oliveiro wrote:

In message <87************@benfinney.id.au>, 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.

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 [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

[Ben Finney]

Steve Holden <st***@holdenweb.comwrites:

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.

--
\ "I wish there was a knob on the TV to turn up the intelligence. |
`\ There's a knob called 'brightness' but it doesn't work." -- |
_o__) Eugene P. Gallagher |
Ben Finney

[Steve Holden]

Ben Finney wrote:

Steve Holden <st***@holdenweb.comwrites:

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

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 [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 <ma**************************************@python.o rg>, 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.

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

I'll bet they are.

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

[Hendrik van Rooyen]

"Lawrence D'Oliveiro" <ldo@ge...ew_zealandwote:

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

<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.supernews.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.supernews.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**************************************@python.o rg>, 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
implementation 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
"overwriting 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.au>, 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 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.

--
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.supernews.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.supernews.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.path)

<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.au>, 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.supernews.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.path)

<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

[Lawrence D'Oliveiro]

In message <ma**************************************@python.o rg>, Robert
Kern wrote:

Lawrence D'Oliveiro wrote:

>In message <13*************@corp.supernews.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.path)

<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.supernews.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.path)

<type 'int'>

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

This is bad faith.

>>import os
type(os.path)

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

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

>>base64.binascii

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

>>fileinput.sys

<module 'sys' (built-in)>

>>fileinput.os

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

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

>>>base64.binascii

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

>>>fileinput.sys

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

[Marc 'BlackJack' Rintsch]

On Sat, 06 Oct 2007 19:16:47 +1300, Lawrence D'Oliveiro wrote:

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?

I'm no C++ expert but I'd say the type is attached to the value too there.
Same is true for Java.

Ciao,
Marc 'BlackJack' Rintsch