[Python-ideas] Module aliases and/or "real names"
Michael Foord
fuzzyman at voidspace.org.uk
Thu Jan 6 13:21:15 CET 2011
On 06/01/2011 01:52, Nick Coghlan wrote:
> On Thu, Jan 6, 2011 at 3:45 AM, Michael Foord<fuzzyman at voidspace.org.uk> wrote:
>> On 5 January 2011 15:57, Nick Coghlan<ncoghlan at gmail.com> wrote:
>>> The two examples I looked at (functools and datetime) favoured hiding
>>> the implementation details at the cost of causing introspection
>>> problems. Despite my comments in the opening post of the thread, I
>>> think that is the better trade-off to make.
>> Both of those are because of underlying C implementations where
>> introspection problems would be the default anyway, which isn't quite the
>> same for situation for unittest.
> True, but it means the precedent of using __module__ to refer to the
> official location rather than than the actual location has already
> been set. That suggests to me our best way forward is to bless that as
> a recommended practice, then find a way to deal with the negative
> impact it currently has on introspection (such as a "__real_module__"
> attribute, as I suggested in another post).
>
Well, I would say set __module__ to the official location *when* we have
"__real_module__" (or whatever) in place.
Changing __module__ breaks inspect.getsource:
.>>> import inspect
.>>> from unittest import TestCase
.>>> TestCase.__module__
'unittest.case'
.>>> TestCase.__module__ = 'unittest'
.>>> inspect.getsource(TestCase)
Traceback (most recent call last):
...
IOError: could not find class definition
As the only problem this solves is a theoretical one (so far for
unittest anyway) I'm not keen to do this until the introspection issue
is resolved. One this is resolved I'm fine with it.
All the best,
Michael
> Cheers,
> Nick.
>
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
More information about the Python-ideas
mailing list