> > > > I'm not sure if the two-step approach is a big enough deal to > > > > keep it in a new import scheme. > > > > > > does anyone remember/know why it was done in two steps? > > > > So you can check whether a module or package exists without importing > > it? > > I have no idea how useful that is in practice. Me neither. > > For the relative import ambiguity? > > This is not true at find-module-time: if module x.y does "import z" > two things are tried: > > - Find 'z' on x.__path__ > We know up front that *if* that suceeds that the full name is "x.z", > so you might as well attempt to *load* "x.y". > > if the above failed: > > - Find 'z' on sys.path, in which case the full name is "z". > > It doesn't matter much, though, in that as long as we don't want to > rewrite import.c as a whole we're stuck with the two-step scheme > anyway. The problem with trying to load x.y right away is that then you can't distinguish between "x.y doesn't exist" (and then you go to step 2) as opposed to "x.y exists, but it tries to import something else that raised ImportError" (and then you should simply propagate the exception). --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