On Tue, Apr 06, 2004, Barry Warsaw wrote:
> On Sat, 2004-04-03 at 13:24, Bernhard Herzog wrote:
>>
>> I don't think this is a good description of the actual problem. The
>> problem is that the modules in the package shadow global ones and
>> there's no easy way to bypass the local package. FWIW, though, I don't
>> recall ever running into a problem with that.
>
> It happens, and it makes for tricky choices. I know to stay away from
> internal modules like re and email, but as the standard library gets
> fatter, there's more chance of collision. The only remedy will be to
> rename an internal module when I find that I suddenly want to use some
> new standard module. There should be more independence.
Thanks! Here's my rewrite; comments, anyone?
Rationale for Absolute Imports
==============================
In Python 2.3 and earlier, if you're reading a module located inside a
package, it is not clear whether ::
import foo
refers to a top-level module or to another module inside the package.
As Python's library expands, more and more old modules suddenly shadow
builtin modules by accident. It's a particularly difficult problem
inside packages because there's no way to specify which module is meant.
To resolve the ambiguity, it is proposed that ``foo`` will always be a
module or package reachable from ``sys.path``. This is called an
absolute import.
The python-dev community chose absolute imports as the default because
they're the more common use case and because absolute imports can provide
all the functionality of relative (intra-package) imports -- albeit at
the cost of difficulty when renaming package pieces higher up in the
hierarchy or when moving one package inside another.
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
Why is this newsgroup different from all other newsgroups?
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