Hi,
I just pushed an even simpler test case that shows the defect:
https://github.com/lelit/buildout/commit/1dc3d6af0b6326500ad72798352dd1537364b5ac
that hopefully will help spotting the bug (or maybe my bad usage of the
extends functionality :-)
I already tried to tweak the
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
