> > > Circular imports, to be made consistent, would need > > > something like a final "commit" after all imports succeeded. > > > > Silly idea. Typically, circular imports aren't planned, they just > > happen, and (usually) just happen to work. > > I thought Christian meant this was something that would > be done automatically, not something the user would have > to do explicitly. OK, I misunderstood then. Apologies to Christian. > Maybe it could be as simple as saving a snapshot of > sys.modules whenever importing of a module is begun, > and if execution of its body doesn't complete, restoring > the snapshot? That sounds like overkill -- any modules that don't participate in the cycle but happen to be imported by one of the modules in the cycle would also be deleted. I still expect that the solution that Tim just checked in (delete any module that failed to complete execution) will solve most of the problems encountered in real life. I'm aware of the case you describe here: > No, it's not. If A and B import each other, and A fails after > importing B, then B ends up with a reference to a broken A > even though it executed without error. But I don't lose sleep over it; this would only be a problem if the main code attempts to import A but suppresses the import error *and* also uses B directly. This doesn't seem to be a likely scenario (modules that can be missed rarely participate in cycles). --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