On Wed, 2003-12-17 at 23:55, Guido van Rossum wrote: > This can be interpreted in two ways though. You could be unfortunate > enough to create a module in your package that has the same name as a > standard module you also need to import from inside the same package > -- that's currently impossible. Right, and I'd like to make that possible. The least disruptive way I see of doing that is to introduce a magic root package from which things can be imported from. E.g. import __root__.re > But the most common variant I've seen > is what Tim Peters describes: having a module in the current directory > that accidentally hides a standard module. Yep, I've been bit by that too. > The latter case does not involve packages and will not be fixed by any > import syntax -- it can only be fixed by changing the default sys.path > *not* to include the current directory, just like over the last decade > or so Unix shells have stopped putting '.' in $PATH. Yep. I haven't had '.' in my $PATH for a bazillion years. :) > But that has other downsides: it would be a lot harder to begin > writing a program broken up into modules. Hmm, maybe the current > directory should be last? That way you can import your own modules > except if they clash with the standard library. Hm, but there are so > many standard library modules that it might still cause frequent > complaints from mystified beginners. > > I'm beginning to agree (uselessly) with Tim: import itself is a > problem. :-) There ya go! That's thinking outside the box: let's deprecate import altogether :) -Barry
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