On 4 January 2011 22:52, Guido van Rossum <guido@python.org> wrote:

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?

So should I do this in unittest for Python 2.7 / 3.2?

The problem this *would* solve is that pickled unittest objects from 2.7 / 3.2 can't be unpickled on earlier versions of Python.

I don't know how *real* a problem it is or whether it is worth losing / faking the __module__ information on these classes to solve it. Sure it's a problem that is likely to bite *someone* at some point, but not very many people. If someone is using __module__ information to find source code (or anything else) for a class then changing __module__ will break that, so I'm not convinced it's a worthwhile tradeoff.

All the best,

Michael

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@gmail.com> wrote:
> On Thu, Dec 30, 2010 at 11:48 AM, Ron Adam <rrr@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@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)

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas