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
On Thu, Dec 30, 2010 at 11:48 AM, Ron Adam
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@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)