This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.moore
Recipients
Date 2002-12-18.09:26:00
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=113328

Be aware that this doesn't solve all of the issues (although it 
does solve a large class of them). Some applications require 
a real filename (wxPython did until recently for image data) 
and some need to stat the file (Guido quoted Zope).

At the very least it should be made clear that this is an 
*optional* part of the interface. Application code should 
always be prepared for an importer not to support get_data (if 
only by saying it can't work from a data store managed by 
this sort of hook).

My preference is for keeping the importer interface minimal 
and clean. At the moment 2 functions (find_module and 
get_module) are all that is required - and these can be in 
separate classes. Which class should have the get_data 
method? Which class gets assigned to __importer__? Is it 
the hook's responsibility to set __importer__ (yet another 
responsibility)?

I think it's time for a PEP. Not for zipimporter, but purely for 
the import hook interface. That would be the place to argue 
such issues as I raised in the paragraph above. We need to 
remain clear on what the API requires vs what zipimporter 
does, to give writers of new hooks a decent chance.
History
Date User Action Args
2007-08-23 15:18:58adminlinkissue652586 messages
2007-08-23 15:18:58admincreate