On Sun, Aug 1, 2010 at 1:36 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote: > On 31/07/2010 16:30, Nick Coghlan wrote: >> With my change, that code would work just fine. "from myproject.gizmo >> import main" and "from __main__ import main" would just return the >> same object, whereas currently they return something different. >> > > Have you looked at the code in that example? I don't think it would work... Ah, I see what you mean - yes, there would need to be some additional work done to detect the case of direct execution from within a package directory in order to set __main__.__package__ accordingly (as if the command line had been "python -m myproject.gizmo" rather than "python myproject/gizmo.py"). Even then, the naming problem would remain. Still, this kind of the thing is the reason I'm reluctant to arbitrarily change the existing semantics - as irritating as they can be at times (with pickling/unpickling problems being the worst of it, as pickling in particular depends on the value in __name__ being correct), people have all sorts of workarounds kicking around that need to be accounted for if we're going to make any changes. I kind of regret PEP 366 being accepted in the __package__ form now. At one point I considered proposing something like __module_name__ instead, but I didn't actually need that extra information to solve the relative import issue, and nobody else mentioned the pickling problem at the time. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4