Module/package hierarchy and its separation from file structure

[Steven D'Aprano]

On Tue, 29 Jan 2008 13:44:33 -0600, Robert Kern wrote:

> Carl Banks wrote:
>> On Jan 29, 7:48 am, Peter Schuller <peter.schul... at infidyne.com> wrote:
>>>> You can also put, in animal/__init__.py:
>>>>  from monkey import Monkey
>>>> and now you can refer to it as org.lib.animal.Monkey, but keep the
>>>> implementation of Monkey class and all related stuff into
>>>> .../animal/monkey.py
>>> The problem is that we are now back to the identity problem. The class
>>> won't actually *BE* org.lib.animal.Monkey.
>> 
>> The usage is the same; it works in all cases once you redefine
>> __module__.  Who cares what it really is?
> 
> The inspect module.

[snip example]

I call that a bug in the inspect module. In fact, looking at the source 
for the findsource() function, I can see no fewer than two bugs, just in 
the way it handles classes:

(1) it assumes that the only way to create a class is with a class 
statement, which is wrong; and 

(2) it assumes that the first occurrence of "class <name>" must be the 
correct definition, which is also wrong.


It isn't hard to break the inspect module. Here's an example:


>>> import broken
>>> import inspect
>>> lines, lineno = inspect.findsource(broken.Parrot)
>>> lines[lineno]
'class Parrot which will be defined later.\n'
>>> 
>>> lines, lineno = inspect.findsource(broken.Wensleydale)
>>> lines[lineno]
'class Wensleydale: # THIS IS GONE\n'

Here's the source of broken.py:


$ cat broken.py
"""Here is a doc string, where I happen to discuss the
class Parrot which will be defined later.
"""
class Parrot:
    pass

class Wensleydale: # THIS IS GONE
    pass

del Wensleydale
class Wensleydale(object):  # but this exists
    pass



It isn't often that I would come right out and say that part of the 
Python standard library is buggy, but this is one of those cases.


-- 
Steven