[Python-Dev] PEP 395: Module Aliasing

[Ron Adam]

On 03/05/2011 01:14 AM, Nick Coghlan wrote:
> On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam<rrr at ronadam.com>  wrote:
>>> Fixing direct execution inside packages
>>
>> +1 on both of these.
>>
>> I don't see any major problems with these.  Any minor issues can be worked
>> out.
>>
>> I suggest separating these two items out into their own PEP, and doing them
>> first.
>
> This first draft includes everything I *want* to do. If I have to
> scale the proposal back to get it accepted because I can't convince
> enough other people it's a good idea... well, even Guido isn't immune
> to that part of the PEP process (cf. PEP 340). It wouldn't be the
> first PEP to have a "Rejected Ideas" section, and I'm sure it wouldn't
> be the last.

Right, All of the reasons are good and some solution should be implemented 
for each of the issues you pointed out. The PEP process will help us figure 
out the best way to do that.


> I definitely intend to implement this in a few different pieces,
> though - the order of the 4 different fixes in the PEP also summarises
> what I consider to be a reasonable development strategy as well.

Sounds good.

I haven't formed a good opinion on the last 2 items yet which was why I 
didn't comment on them.




This morning I did have some interesting thoughts.*

*It seems I'm starting to wake up with python code in my head.  (Is that 
good?)  In some cases, it's outside of the box solutions, but not always 
good ones. <shrug> ;-)


Anyway... this mornings fuzzy python thoughts were along the lines of...


On one hand, Python tries to make it so each objects source/parent info  is 
reachable from the object when possible.  The nice thing about that is, it 
can be used to create a tree of where everything is.  That doesn't work 
*easily* at the module level due to modules being external OS entities that 
can be reused in different contexts.

On the other hand, a modules import order is somewhat more dynamic compared 
to class inheritance order, so would it be better to have that info in a 
separate place rather than with each module?


Adding a second references to the '__main__' module begins to blur the 
purpose of sys.modules from being a place to keep imported modules to a 
place that also has some ordering information.  (Practicality over purity?, 
Or an indication of what direction to go in?)

And, if you ask for keys, items, or values, you will need to filter out 
'__main__' to avoid the double reference.


So I was thinking, what if we make sys.modules a little smarter.  The 
negative of that is, it would no longer be a simple dictionary object.


First idea ...

Add a __main__ attribute to sys.modules to hold the name of the main module.

Override modules.__setitem__, so it will catch '__main__' and set 
modules.__main__ to the name of the module, and put the module in under its 
real name instead of '__main__'.

Override modules.__getitem__, so it will catch '__main__' and return 
self[self.__main__].

Then keys(), values(), and items(), will not have the doubled main module 
references in them.

The name of the main module is easy to get.  ie... sys.modules.__main__

sys.modules[__name__] will still return the correct module if __name__ == 
"__main__".



Second (more ambitious and less thought out) idea ...

Extend sys.modules so it is actually is a tree structure. The '__main__' 
module would be at the top of the tree.


Cheers,
    Ron