On 03/05/2011 01:14 AM, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam<r...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
