Rocky Bernstein wrote: > As best as I can tell, PEP 302 which discussed importer hooks and > suggests a standard way to get file data. But it doesn't address a > standard way to get container package and/or loader information.
If a "filename" may not be an actual filename, but instead a pseduo-filename created based on the __file__ attribute of a Python module, then there are a few mechanisms for accessing it: 1. Use the package/module name and the relative path from that location, then use pkgutil.get_data to retrieve it. This has the advantage of correctly handling the case where no __loader__ attribute is present (or it is None), which can happen for standard filesystem imports. However, it only works in Python 2.6 and above (since get_data() is a new addition to pkgutil). 2. Implement your own version of pkgutil.get_data - more work, but it is the only way to get something along those lines that works for versions prior to Python 2.6 3. Do what a number of standard library APIs (e.g. linecache) that accept filenames do and also accept an optional "module globals" argument. If the globals argument is passed in and contains a "__loader__" entry, use the appropriate loader method when processing the "filename" that was passed in. > Also I'm not sure there *is* a standard print string way to show > member inside a package. zipimporter may insert co_filename strings > like: > > /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py > > but the trouble with this is that it means file routines have to scan > the path and notice say that > /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg is a *file*, > not a directory. And a file stat/reading routine needs to understand > what kind of packager that is in order to get tracer.py information. > > (Are there any file routines in place for doing this?) Finding a loader given only a pseudo-filename and no module is actually possible in the specific case of zipimport, but is still pretty obscure at this point in time: 1. Scan sys.path looking for an entry that matches the start of the pseudo-filename (remembering to use os.path.normpath). 2. Once such a path entry has been found, use PEP 302 to find the associated importer object (the undocumented pkgutil.get_importer function does exactly that - although, as with any undocumented feature, the promises of API compatibility across major version changes aren't as strong as they would be for an officially documented and supported interface). 3. Hope that the importer is one like zipimport that allows get_data() to be invoked directly on the importer object, rather than only providing it on a separate loader object after the module has been loaded. If it needs a real loader instead of just the importer, then you're back to the original problem of needing a module or package name (or globals dictionary) in addition to the pseudo filename. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
