[Alex Coventry] > > Hi, I posted a patch recently, #441791, causing "import > > foo.bar" to set "sys.modules['foo'].bar = > > sys.modules['foo.bar']" even if an error is raised during the > > importing of bar. With this patch, import commands like > > "import foo.bar; reload(foo.bar)" work in a fashion more > > consistent with the way "import unpackaged_module; > > reload(unpackaged_module)" works. [Guido] > In any case, I agree it would be nice if this was fixed. Import issues are subtle, but this looks good to me. > Maybe Thomas was thinking of a different issue, where some people > want the sys.modules[name] entry to be *removed* when an import > fails. I am not for that change, but I haven't recovered the > reason (I know I had a good one when I implemented things this > way). Perhaps one could construct a situation with circular imports in which one module ends up with a name (and no error, because the name is being imported) that later turns into an error? There's also the issue of failed relative imports that succeed as absolute imports - you don't want every module in the package hunting around for package.sys. - Gordon
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