On Thu, Dec 30, 2010 at 11:48 AM, Ron Adam firstname.lastname@example.org 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.