On Thu, Dec 30, 2010 at 6:52 PM, Nick Coghlan <firstname.lastname@example.org
> On Thu, Dec 30, 2010 at 11:48 AM, Ron Adam <email@example.com
>> 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
> 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
> 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