On Jul 27, 2006, at 3:52 AM, Georg Brandl wrote: > Armin Rigo wrote: >> Hi Phillip, >> >> On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote: >>> If we don't revert it, there are two ways to fix it. One is to >>> just change >>> PEP 302 so that the behavior is unbroken by definition. :) The >>> other is >>> to actually go ahead and fix it by adding PathImporter and >>> NullImporter >>> types to import.c, along with a factory function on >>> sys.path_hooks to >>> create them. (This would've been the PEP-compliant way to >>> implement the >>> need-for-speed patch.) >>> >>> So, "fix" by documentation, fix by fixing, or fix by reverting? >>> Which >>> should it be? >> >> "fix" by changing the definition looks like a bad idea to me. The >> import logic is already extremely complicated and delicate, any >> change >> to it is bound to break *some* code somewhere. > > Though beta1 and beta2 shipped with this change nobody reported any > bug that > could be linked to it. sys.path_importer_cache is quite an internal > thing and > most code, even import hooks, shouldn't have to deal with it.
Anyone trying to emulate what imp.find_module does in a PEP 302 compliant way will need to introspect sys.path_importer_cache. I have some unreleased code based on the PEP 302 spec that does this and the way it was originally written would have broke in 2.5 if I had tested it there. Just because it's obscure doesn't mean we should go change how things work in a way that's not consistent with the documentation. The documentation should change to match the code or vice versa, though I really don't have any strong feelings one way or the other. -bob _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com