[Python-ideas] Module aliases and/or "real names"

[Nick Coghlan]

On Mon, Jan 10, 2011 at 9:37 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> I certainly don't object to fixing this, and neither do I object to adding a
> new class / module / function attribute to achieve it.
>
> However... is there anything else that this fixes? (Are there more examples
> "in the wild" where this would help?)
>
> The unittest problem with pickling is real but likely to only affect a very,
> very small number of users. The introspection problem (getsource) for
> functools and datetime isn't a *real* problem because the source code isn't
> available. If in fact getsource now points to the pure Python version even
> in the cases where the C versions are being used then "fixing" this seems
> like a step backwards...

unittest is actually a better example, because there *is* a solution
to your pickling problem: alter __module__ to say "unittest" rather
than "unittest.<whatever>", just as _functools.partial and the
_datetime classes do. However, you've stated you don't want to do that
because it would break introspection. That's a reasonable position to
take, so the idea is to make it so you don't have to make that choice.
Instead, you'll be able to happily adjust __module__ to make pickling
work properly, while introspection will be able to fall back on
__impl_module__ to get the correct information.

> Python 3.2:
>>>> import inspect
>>>> from datetime import date
>>>> inspect.getsource(date)
> 'class date:\n    """Concrete date type.\n\n ...'
>
> Python 3.1:
>>>> import inspect
>>>> from datetime import date
>>>> inspect.getsource(date)
> Traceback (most recent call last):
>   ...
> IOError: source code not available
>
> With your changes in place would Python 3.3 revert to the 3.1 behaviour
> here? How is this an advantage?

It's an improvement because the current answer is misleading: that
source code is *not* what is currently running. You can change that
source to your heart's content and it will do exactly *squat* when it
comes to changing the interpreter's behaviour.

That said, one of the benefits of this proposal is that we aren't
restricted to the either/or behaviour. Since the interpreter will
provide both pieces of information, we have plenty of opportunity to
make inspect smarter about the situation. (e.g. only looking in
__impl_module__ by default, but offering a flag to also check
__module__ if no source is available from the implementation module).

> What I'm really asking is, is the cure (and the accompanying implementation
> effort and additional complexity to the Python object model) worse than the
> disease...

Potentially, but I see enough merit in the idea to follow up with a PEP for it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia