Module/package hierarchy and its separation from file structure

[Peter Schuller]

Well, all I will say is that many people on this list, myself

included, do know Python internals, and we use the method we've been
suggesting here, without problems.

Ok. That is useful to know (that it is being done in practice without
problems).

Thanks!

--
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <[email protected]>'
Key retrieval: Send an E-Mail to (e-mail address removed)
E-Mail: (e-mail address removed) Web: http://www.scode.org

 

[Peter Schuller]

It what sense will it not be? Why do you care so much about where the

source code for Monkey is defined? If you actually want to read the
source, you might need to follow the chain from "animal", see that Monkey
is imported from "monkey", and go look at that. But the rest of the time,
why would you care?

There is a very good reason to care *in practice*: if there is code out
there that assumes that the source code from Monkey is in the file it was
found in. In practice, you might be stuck needing to work around that.
But that's not a good reason to care *in principle*. In principle, the
actual location of the source code should be an implementation detail of
which we care nothing. It's possible that the source for Monkey doesn't

Exactly. I *DON'T* want anything to depend on the physical location on disk.
That was exactly what I was after from the beginning; a total separation of
location on disk from the location in the module hiearachy. As you say, the
location of the source should be an implementation detail. That is exactly
what I am after.

I'll have a closer look at the suggested practice of modifying __module__.

For this particular use case we probably won't end up doing that, but it
may come to be useful in the future.

--
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <[email protected]>'
Key retrieval: Send an E-Mail to (e-mail address removed)
E-Mail: (e-mail address removed) Web: http://www.scode.org

 

[Ben Finney]

I *DON'T* want anything to depend on the physical location on disk.

Importing the code in the first place will — unavoidably, it seems to
me — depend on the file location from which to load the module.

After that, nothing depends on the physical location on disk, unless
it's buggy. Imported modules are available from 'sys.modules', and
that's where subsequent 'import' statements will find them, with no
reference to file locations.

That was exactly what I was after from the beginning; a total
separation of location on disk from the location in the module
hiearachy. As you say, the location of the source should be an
implementation detail. That is exactly what I am after.

It *is* an implementation detail, once the module is loaded from disk.

 

[NickC]

Python stores filename and line number information in code objects
(only). If you have a reference to any code object (a method, a
function, a traceback...) inspect can use it to retrieve that
information.

Aside from general concerns about increasing the size of class objects
(and most programs don't contain enough of those to make a big
difference) I don't immediately see anything that would prevent the
interpreter being modified to add file and line number information to
class objects as well. While the information wouldn't always be
present (types implemented in C, types created by calling the
metaclass constructor directly), it would help address the inspect
module bugs Steven illustrated.

I would agree with Carl that modifying __module__ in the way he
suggests is legitimate - if it breaks the inspect module, then it is
the inspect module that needs fixing (and/or better support from the
interpreter to help find the real source code).

Cheers,
Nick.