[Python-ideas] Module aliases and/or "real names"

[Michael Foord]

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



-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others

May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110105/79bdfcea/attachment.html>