[Pythonmac-SIG] Re: [pygame] python + pygame on OSX

[Mitch Chapman]

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 it
>> 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.
>
> But 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.

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.

> 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 responded
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)

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.

--
Mitch