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

[Guido van Rossum]

Hmm... I starred this and am finally dug out enough to comment.

Would it be sufficient if the __module__ attribute of classes and
functions got set to the "canonical" name rather than the "physical"
name?

You can currently get a crude version of this by simply assigning to
__name__ at the top of the module.

That sounds like it would be too confusing, however, so perhaps we
could make it so that, when the __module__ attribute is initialized,
it first looks for __canonical__ and then for __name__?

This may still be too crude though -- I looked at the one example I
could think of where this might be useful, the unittest package, and
realized that it would set __module__ to 'unittest' even for classes
that are not actually re-exported via the unittest namespace.

So maybe it would be better in that case to just patch the __module__
attribute of all the public classes in unittest/__import__.py?

OTOH for things named __main__, setting __canonical__ (automatically,
by -m or whatever other mechanism starts execution, like "python
<filename>" might actually work.

On the third hand, maybe you've finally hit upon a reason why the "if
__name__ == '__main__': main()" idiom is bad...

--Guido

On Thu, Dec 30, 2010 at 6:52 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Thu, Dec 30, 2010 at 11:48 AM, Ron Adam <rrr at ronadam.com> wrote:
>> This sounds like two different separate issues to me.
>>
>> One is the leaking-out of lower level details.
>>
>> The other is abstracting a framework with the minimal amount of details
>> needed.
>
> Yeah, sort of. Really, the core issue is that some objects live in two places:
> - where they came from right now, in the current interpreter
> - where they should be retrieved from "officially" (e.g. since another
> interpreter may not provide an accelerated version, or because the
> appropriate submodule may be selected at runtime based on the current
> platform)
>
> There's currently no systematic way of flagging objects or modules
> where the latter location differs from the former, so the components
> that leak the low level details (such as pickling and pydoc) have no
> way to avoid it. Once a system is in place to identify such objects
> (or perhaps just the affected modules), then the places that leak that
> information can be updated to deal with the situation appropriately
> (e.g. pickling would likely just use the official names, while pydoc
> would display both, indicating which one was the 'official' location,
> and which one reflected the current interpreter behaviour).
>
> So it's really one core problem (non-portable module details), which
> then leads to an assortment of smaller problems when other parts of
> the standard library are forced to rely on those non-portable details
> because that's the only information available.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
--Guido van Rossum (python.org/~guido)