On Mon, Oct 1, 2012 at 12:18 PM, Barry Warsaw ba...@python.org wrote:
On Oct 01, 2012, at 03:43 PM, Vinay Sajip wrote:
As a matter of interest, what are the APIs you're using which need filenames
but can't use bytes or streams?
dlopen() is the canonical example of an API that can only use a
Daniel Holth dholth at gmail.com writes:
dlopen() is the canonical example of an API that can only use a filename.
Okay. Naturally there is already support for absolute paths in the file system
for resources which are in the file system, so the question was really for
resources in zips. Is it
On Tue, Oct 2, 2012 at 2:44 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at gmail.com writes:
dlopen() is the canonical example of an API that can only use a filename.
Okay. Naturally there is already support for absolute paths in the file system
for resources which are
On Oct 02, 2012, at 06:44 PM, Vinay Sajip wrote:
Okay. Naturally there is already support for absolute paths in the file
system for resources which are in the file system, so the question was really
for resources in zips. Is it expected that the scenario will be quite common
to get a .so or
PJ Eby pje at telecommunity.com writes:
Btw, I think you might be missing part of the point of
resource_filename() - it's not just that there are APIs (and external
programs) that need real filenames, but that there are also C APIs
that operate on OS-level file handles, so just having the
Daniel Holth dholth at gmail.com writes:
resource_filename is very popular. I would have thought
resource_stream would be more popular. Unless your package is zipped
resource_filename is trivial to implement.
Yes, I find that odd, too. pkg_resources seems to extract files from zip into a
On Sep 30, 2012, at 10:00 PM, Daniel Holth wrote:
resource_filename is very popular. I would have thought
resource_stream would be more popular. Unless your package is zipped
resource_filename is trivial to implement.
I've used declare_namespace() once or twice.
I use resource_filename(),
On Oct 01, 2012, at 07:35 AM, Vinay Sajip wrote:
Yes, I find that odd, too. pkg_resources seems to extract files from zip into
a cache folder, then returns filenames from the location in the cache; it
seems a lot of trouble to go to just to be able to deliver a filename.
Darn handy though when
On Mon, Oct 1, 2012 at 10:46 AM, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2012, at 10:00 PM, Daniel Holth wrote:
resource_filename is very popular. I would have thought
resource_stream would be more popular. Unless your package is zipped
resource_filename is trivial to implement.
I've
Of course it's not really a mystery; a tremendous number of Apis only accept
a file name. That's why it's there. And only something well connected to
the importer system knows how and whether the extraction is needed.
Why is that the case? If the bytes are available, then whoever needs
Barry Warsaw barry at python.org writes:
a third-party API which expects a filename) can handle that themselves,
e.g. by saving the bytes to a temporary location and passing that to whatever
needs a filename.
Why not provide this by distlib?
Only because it doesn't add much value, and (if
On Oct 01, 2012, at 03:43 PM, Vinay Sajip wrote:
Barry Warsaw barry at python.org writes:
Why not provide this by distlib?
Only because it doesn't add much value, and (if you do all that pkg_resources
does) might mean that you have to maintain a cache.
Well, it's just something that client
I thought it would be interesting to get an idea of the relative
popularity of the various pkg_resources calls in the interest of
emulating a subset. So I looked it up on Nullege. The absolute
popularity is certainly different from the numbers below.
I think of require() and load_entry_point()
13 matches
Mail list logo
