[Python-Dev] Release manager pronouncement needed: PEP 302 Fix (original) (raw)

Bob Ippolito bob at redivi.com
Thu Jul 27 19:04:35 CEST 2006

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.pathhooks 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.pathimportercache 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

More information about the Python-Dev mailing list