[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

On Feb 23, 2004, at 9:42 PM, Mitch Chapman wrote:


On Feb 23, 2004, at 2:02 AM, Jack Jansen wrote:
Implementation is going to be peanuts, design is what we want.
We should investigate the paradigms people use nowadays to get at their datafiles, and come up with something that is as close as possible to that.

How does pygame find its datafiles?
When we were involved in development with pygtk we stored data files in
subdirectories of the toplevel Python package for ease of distribution.
We found the data files by searching on the Python path.

The technique is documented in this article:
http://www2.linuxjournal.com/lj-issues/issue87/4702.html

I have updated the module PathFinder.py described in the article.  The
new version recognizes zip files in the Python path. If one of the zip
files contains the data file being sought, then the data file is
extracted to a temporary directory, preserving filename suffix.  The
location of the extracted file is remembered in case another client
seeks it.  At the end of the Python session the temporary files are
removed.

Use of the module is pretty simple:

import PathFinder
try:
    jpegPathname = PathFinder.find("images/sample.jpg")
except PathFinder.Error, info:
    ...

If any of this sounds relevant I can post a tarball containing the
module and a regression test.
Extracting data from zip files is not strictly desired or necessary as we have bundles on OS X, temp files suck, most data files probably aren't going to compress very well anyhow.

Things I don't like about this implementation:

* It's up to the module developer to ensure that their "images/sample.jpg" is a unique filename that another module developer will not use or else PathFinder might find the wrong file. This is very bad, because if the module developers can screw this up they definitely will. Forcing them to specify a key, like __name__ or perhaps "org.pygame", is more sensible because it isolates packages from each other.

* What if you want to make this all work over a network or something crazy like that? You have to go through all the trouble of injecting a different PathFinder, which is Really Hard because people are going to include PathFinder with their packages to reduce dependencies, especially because Python doesn't yet make non-relative imports easy. If we're stuffing something new down people's throats it should be extensible like my proposed interface-adaptation-based solution would be. The provider of this resource-finding-service should be up to the packaging software (py2exe, bundlebuilder, etc.) or a default stupid __file__ based implementation, not some do-everything-for-everyone-cross-platform-predict-the-future module.

-bob