On 01/09/2011 12:18 PM, Nick Coghlan wrote:
On Mon, Jan 10, 2011 at 3:56 AM, Ron Adamrrr@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__ '/usr/local/lib/python3.2/dis.py'
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 directly.
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.