[Python-ideas] Module aliases and/or "real names"
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
>>>> different *other* locations. A virtual module would need a way to keep
>>>> 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
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
<module 'dis' from '/usr/local/lib/python3.2/dis.py'>
>>> import builtins
<module 'builtins' (built-in)>
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.
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