On Feb 24, 2004, at 9:24 AM, Mitch Chapman wrote:
Yeah, but people aren't going to do it that way if the API doesn't make it blatantly obvious.On Feb 23, 2004, at 11:12 PM, Bob Ippolito wrote:I think you may have misread the code. PathFinder uses the same path resolution techniques as Python itself (with the exception that itBut the python import mechanism knows what module you're importing from, your API does not. sys.path is a fallback mechanism gets used if the module can not be found relative to the module doing the importing. Your mechanism ONLY uses the fallback mechanism, so if pygame wants "image/sample.jpg" and foobazmodule wants "image/sample.jpg", it's not really possible to have both of them get what they want without an API change.
doesn't use sys.meta_path). That is, it searches every
entry on sys.path, seeing if the relative path supplied by the caller
can be resolved by joining with the current sys.path entry.
Yes, that's true: PathFinder.find needs always to be used as though the caller were importing the required data file from a package, and it requires Guido's recommended usage for package path specifiers. (From PEP 8: "Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports.") And that's not evident from the API.
Yeah, but writing import hooks is a real PITA. I'm sure you know this :)In any case, a more flexible version based on interfaces and adaptation would allow artbitrary-packaging-software to provide zip, rar, http, encrypted, or whatever data file support it needs.
In fact Python 2.3's import mechanism is also designed to support this, although it implements only zip and "regular file" imports at present.
Jack asked for a focus on design. Maybe I should have respondedThe example I gave was basically _the entire implementation_ sans PyProtocols, I wouldn't dare actually forcing that API on people. It would be wrapped up in a module that people would stuff in their packages. In fact, such a module could still work even if PyProtocols is not available by using dummy objects for the protocols and having adapt just call the factory.. which eliminates all dependencies. That's basically how ZODB works in relation to Zope X3's components, if it's not available it will just use dummy objects.
to that before responding to his request for examples of how people
are getting at data now.
I'd like to see a system which locates data files in the same way as
Python's import mechanism (so as _not_ to "stuff something new down
people's throats"). It should produce the representations of
loaded data required by consuming APIs (pathnames, in both my examples
and my experience) "out of the box", while being extensible as you
recommend.
And it should present a simple end-user API. That's why
I dislike this proposal -- it makes even the most common use case
tedious:
myResourceFileObj = adapt((__module__, "resourcefilename"), IReadableFileLike, factory=defaultFactory)
My biggest problem is that it's going to be hard to get people to use a PathFinder-like solution if the user has to install the thing separately, unless it comes with Python or at least has a really good chance of coming with Python. It can't be usefully embedded in every package due to the fact that it needs to have a single global registry in order to do its job properly.The import implementation in Python 2.3 supports most of these requirements, except that it produces only loaded modules. Perhaps it would be a good starting point for a design.