On Sun, Apr 15, 2012 at 8:32 AM, Guido van Rossum <gu...@python.org> wrote: > Funny, I was just thinking about having a simple standard API that > will let you open files (and list directories) relative to a given > module or package regardless of how the thing is loaded. If we > guarantee that there's always a __loader__ that's a first step, though > I think we may need to do a little more to get people who currently do > things like open(os.path.join(os.path.basename(__file__), > 'some_file_name') to switch. I was thinking of having a stdlib > function that you give a module/package object, a relative filename, > and optionally a mode ('b' or 't') and returns a stream -- and sibling > functions that return a string or bytes object (depending on what API > the user is using either the stream or the data can be more useful). > What would we call thos functions and where would the live?
We already offer pkgutil.get_data() for the latter API: http://docs.python.org/library/pkgutil#pkgutil.get_data There's no get_file() or get_filename() equivalent, since there's no relevant API formally defined for PEP 302 loader objects (the closest we have is get_filename(), which is only defined for the actual module objects, not for arbitrary colocated files). Now that importlib is the official import implementation, and is fully PEP 302 compliant, large sections of pkgutil should either be deprecated (the import emulation) or updated to be thin wrappers around importlib (the package walking components and other utility functions). 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