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

Ron Adam rrr at ronadam.com
Mon Jan 10 02:11:45 CET 2011

On 01/09/2011 12:18 PM, Nick Coghlan wrote:
> On Mon, Jan 10, 2011 at 3:56 AM, Ron Adam<rrr at ronadam.com>  wrote:
>> On 01/09/2011 12:39 AM, Nick Coghlan wrote:
>>>> Also consider having virtual modules, where objects in it may have come
>>>> from
>>>> different *other* locations. A virtual module would need a way to keep
>>>> track
>>>> of that. (I'm not sure this is a good idea.)
>>> It's too late, code already does that. This is precisely the use case
>>> I am trying to fix (objects like functools.partial that deliberately
>>> lie in their __module__ attribute), so that this can be done *right*
>>> (i.e. without having to choose which use cases to support and which
>>> ones to break).
>> Yes, __builtins__ is a virtual module.
> No, it's a real module, just like all the others.

As George pointed out it's "builtins".  But you knew what I was referring 
to. ;-)

I wasn't saying it's not a real module, but there are differences.  Mainly 
builtins (and other c modules) don't have a file reference after it's 
imported like modules written in python.

 >>> import dis
 >>> dis
<module 'dis' from '/usr/local/lib/python3.2/dis.py'>
 >>> dis.__file__

 >>> import builtins
 >>> builtins
<module 'builtins' (built-in)>
 >>> builtins.__file__
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__file__'

So they appear as if they don't have a source.  There is probably a better 
term for this than virtual.  I was thinking it fits well for modules 
constructed in memory rather than ones built up by executing python code 


Should modules written in other languages have a __file__ attribute?

Would that help introspection or in other ways?

>> It's this loading part that can be improved.
> I don't understand the point of this tangent. The practice of how
> objects are merged into modules is already established: you use
> "import *" or some other form of import statement. I want to *make
> that work properly*, not invent a new way to do it.

Sorry, I was looking for ways to avoid changing __module__.

All of the above ways, will still have the __module__ attribute on objects 
set to the module they came from.  Which again is fine, because that is 
what you want most of the time.  Just not in the case of partial.

Setting __module__ manually is easy enough in that case.

 > Cheers,
 > Nick.

I think I'm more likely to side track you at this point.  I am starting to 
get familiar with the c code, but I still have a ways to go before I 
understand all the different parts.  Getting there though. :-)

On the python side of things, the attributes we've been discussing almost 
never have anything to do with what most programs are written to do. Unless 
it's a program written specifically for managing pythons various parts. 
It's kind of like the problem of separating content, context, and 
presentation in web pages.  Sometimes it's hard to do.


More information about the Python-ideas mailing list