[Python-Dev] 2.5b3, commit r46372 regressed PEP 302 machinery (sf not letting me post) (original) (raw)

Robin Bryce robinbryce at gmail.com
Wed Aug 9 10:09:50 CEST 2006

This has an sf number now #1537167, and hopefully a clearer explanation of what I think the problem is. This is not a duplicate of the earlier "PEP 302 Fix" thread.

Thanks, Robin

On 07/08/06, Robin Bryce <robinbryce at gmail.com> wrote:

Hi,

Appologies for the lack of an sf#. I tried to submit this there but couldn't. (sf is logging me out each time I visit a new page and it is refusing my attempt to post anonymously). Python 2.5b3 (trunk:51136M, Aug 7 2006, 10:48:15) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2

The need for speed patch commited in revision r46372 included a change whose intent was to reduce the number of open calls. The continue statement at line 1283 in import.c:r51136 has the effect of skipping the builtin import machinery if the findmodule method of a custom importer returns None. In Python 2.4.3, if findmodule returned None the builtin machinery is allowed to process the path tail. In my particular case I am working on an importer that deals with kid templates that may or may not exist as .py[c] files. The short of it is that in Python 2.4.3 this produces a usable module _import_('foo.a/templateuri') wheras in 2.5b3 I get import error. The python 2.4.3 implementation allows module paths that are not seperated with '.' Python 2.5b3 does not allow this and it does not look like this was an intentional change. I believe this point about 'illeagal' module paths is actualy independent of the regresion I am asserting. Detailed session logs are attatched (following the sf guidance even though I'm posting to py-dev) The 'use case' for the importer is: Robin wants to package a default template file as normal python module and provide a custom importer that allows users of his package to reference both: there own templates and html files on the file system in arbitrary locations AND the stock templates provided as python modules under the same name space. He would like to leave normal imports to the standard machinery. Cheers, Robin

More information about the Python-Dev mailing list