At 08:53 PM 5/19/04 +0200, Bernhard Herzog wrote: >Guido van Rossum <guido at python.org> writes: > > >> > Because in the current situation the meaning of an import is > >> > ambiguous. > >> > >> What exactly is ambiguous about it? > > > > Looking at "import foo" you can't tell whether there's a module foo > > expected in the current package or in the top-level module namespace. > >Well, looking at "print foo" I can't tell whether its a local variable, >a global variable or a builtin either. Nobody's going to suggest we >should introduce special syntax to distinguish them, I hope. Module >import isn't much different Yes it is, actually. You can answer the "print foo" question simply by inspecting the code of the function that contains it. (And if it's not in a function, you know it's a global, unless it's never assigned, in which case it's a builtin.) But the "import foo" question cannot be answered by referring to the source of the module in which it occurs. >Absolute imports have their own difficulties, too, btw, and relative >imports don't add much complexity on top of that. I don't think the >ambiguity, if you want to call it that, is enough of a problem to >justify the incompatibility. IIRC, nobody has suggested eliminating them prior to 3.0, which will have lots of other backward-incompatible changes anyway.
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