I'm in general in favor of this. I will accept it once there is a working implementation that is satisfactory. Are we planning on supporting this in 2.6? It might break some 2.5 code that messes with modules and packages? --Guido On 7/10/07, Nick Coghlan <ncoghlan at gmail.com> wrote: > Brett Cannon wrote: > > On 7/9/07, Nick Coghlan <ncoghlan at gmail.com> wrote: > >> Given the above limitations, I propose that we document the new > >> attribute as follows: > >> > >> "If the module global __package__ exists when executing an import > >> statement, it is used to determine the base for relative imports, > >> instead of the __name__ and __path__ attributes. > > > > That's fine. __path__ actually isn't used to resolve relative imports > > into absolute ones anyway; it's used only as a substitute to sys.path > > when importing within a package. > > I was referring to the fact that if __path__ is present (indicating a > package), then the relative import is based directly on __name__, > otherwise it is based on __name__.rpartition('.')[0]. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > --------------------------------------------------------------- > http://www.boredomandlaziness.org > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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