Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Module/package hierarchy and its separation from file structure

Reply
Thread Tools

Module/package hierarchy and its separation from file structure

 
 
Peter Schuller
Guest
Posts: n/a
 
      01-30-2008
> 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 <(E-Mail Removed)>'
Key retrieval: Send an E-Mail to http://www.velocityreviews.com/forums/(E-Mail Removed)
E-Mail: (E-Mail Removed) Web: http://www.scode.org

 
Reply With Quote
 
 
 
 
Peter Schuller
Guest
Posts: n/a
 
      01-30-2008
> 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 <(E-Mail Removed)>'
Key retrieval: Send an E-Mail to (E-Mail Removed)
E-Mail: (E-Mail Removed) Web: http://www.scode.org

 
Reply With Quote
 
 
 
 
Ben Finney
Guest
Posts: n/a
 
      01-31-2008
Peter Schuller <(E-Mail Removed)> writes:

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

--
\ "Philosophy is questions that may never be answered. Religion |
`\ is answers that may never be questioned." —anonymous |
_o__) |
Ben Finney
 
Reply With Quote
 
NickC
Guest
Posts: n/a
 
      02-04-2008
On Jan 31, 12:27 am, Gabriel Genellina <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 14 04-03-2010 10:08 AM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 0 04-01-2010 10:25 PM
Its a bird, its a plane, no ummm, its a Ruide thunk Ruby 1 03-30-2010 11:10 AM
What is the structure hierarchy here? Doru Roman ASP .Net Datagrid Control 3 02-14-2006 09:15 PM
Input form for creating hierarchy structure Marco Alting ASP General 1 08-14-2003 08:19 PM



Advertisments