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

[Bob Ippolito]

On Feb 24, 2004, at 9:24 AM, Mitch Chapman wrote:

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

Yeah, but people aren't going to do it that way if the API doesn't make 
it blatantly obvious.

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

Yeah, but writing import hooks is a real PITA.  I'm sure you know this 
:)

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

PathFinder would be an example of an adapter that an adaptation-based 
solution could use as an alternative to the default os.path.join(...), 
and could even be the canonical implementation for say, py2exe based 
builds.

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

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.

PyProtocols was just an example of a PEP-backed single global registry. 
  With the bonus that it also makes the implementation a whole lot 
simpler and easier to extend than say, import hooks.  Of course, it 
would make your apps about 364k bigger on OS X if you include the whole 
thing (source, bytecode, module w/ debug symbols) but can be stripped 
down to 100k or less before compression by removing source, tests, and 
debugging symbols (most of this is typical executable-packager behavior 
anyway).

-bob