On Tue, 29 Jan 2008 13:44:33 -0600, Robert Kern wrote:
> Carl Banks wrote:
>> On Jan 29, 7:48 am, Peter Schuller <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
