On Wed, Mar 19, 2008 at 11:34 AM, Paul Moore <p.f.moore at gmail.com> wrote: > On 19/03/2008, Guido van Rossum <guido at python.org> wrote: > > On Mon, Mar 17, 2008 at 2:19 PM, zooko <zooko at zooko.com> wrote: > > > 4. The standard Python library includes a tool to find and read > > > resources (other than Python modules) that came bundled in a Python > > > package. > > I think we're pretty close to this already. PEP 302 defines a > > getdata() method. Hopefully most PEP 302 implementations support it. > > The only thing missing IMO is a little function that does what > > getdata() does when there is no __loader__ object (i.e. when the > > default "import-from-filesystem" import method is used). > > I'm currently working on an addition to pkgutil to provide this type > of function. I'm considering going a little further (adding functions > to get a file-like object, test for existence, and list available > resources, modelled on the pkg_resources functions - but these extra > ones are not supported by the loader protocol, so I'm undecided as to > whether it's worth it, I'll see how complex the code gets). I'd only do what __loader__ offers. People can always wrap a StringIO around it. > Once I have a patch, I'll post it to the tracker. What's the best > approach? Code a patch for 3.0 and backport, or code for 2.6 and let > the merging process do its stuff? Code for 2.6, let the merge do its thing. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4