module confusion

[Steven D'Aprano]

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:
<module 'os' from '/usr/lib/python2.5/os.pyc'>


It's quite common.

 

[Steve Holden]

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:

<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 +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 so I couldn't cat it

 

[Neil Cerutti]

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.

 

[Steven D'Aprano]

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.

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

 

[Steve Holden]

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.

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 +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 so I couldn't cat it

 

[Lawrence D'Oliveiro]

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]

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