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...
On Thu, Dec 30, 2010 at 6:52 PM, Nick Coghlan firstname.lastname@example.org wrote:
On Thu, Dec 30, 2010 at 11:48 AM, Ron Adam email@example.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:
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.
-- Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia
Python-ideas mailing list Pythonemail@example.com http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)