From: Guido van Rossum [mailto:guido@python.org] >> My specific issue is with get_data, which is totally unneeded >> for the import protocol itself (although it does solve real, >> related issues). I don't think it should be a requirement of >> the import hook API. Documenting it as an optional interface >> which hooks may choose to support may be reasonable, though. > I like get_data(). The caller should always be prepared for > it to return an error (how does it do that? raise what? or > return None? that should be specified!). An importer that > can't do this should implement a version that always reports > an error. This is much easier on the client than calling > hasattr(importer, 'get_data') first or catching AttributeError. I don't have a big problem with get_data(). But currently, it's badly under-specified. You mention the question of how it returns errors (not just "can't do this" - what about "file not found"?). There's also the question of the exact format of the "filename". Should it be like a module name (dotted)? This has the advantage of matching how the rest of the importer logic works, but the disadvantage of being unnatural to the user. Should it be a pseudo-path format? This has the disadvantage of being platform specific (the zipimporter already jumps through some hoops to convert os.sep/os.altsep into forward slashes (which is what the zip format uses), and other importers may have even more work to do). Or something else? Also is it a method of the object that implements load_module, or the one that implements find_module? I could argue either. I can code things either way. But I don't have enough "real world" experience to say which is best in practice. Paul.
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