[Web-SIG] Standardising containment.
py-web-sig at xhaus.com
Mon Sep 6 17:26:08 CEST 2004
>>>The other main one that springs to mind is how WSGI applications
>>>discover the file-system path name that corresponds to an URI.
>>I thought that one of the major features of most of these Python web
>>frameworks is that a URI doesn't map to a file but to an object or a
>>function, several of which might be in one physical file. Since WSGI
>>seems to be promoted as a minimal system that applies equally to
>>almost any system, I'd think that such a mapping falls entirely out
>>of its scope.
> It probably does for WSGI, although I wonder how such issues (and the
> many others out there) can be simultaneously avoided and yet
> anticipated by the specification in order to avoid incompatibilities
> later on.
And avoiding incompatibility is what I am trying to do.
>>I agree that it might be useful to have this functionality. I think a
>>standard way to map URIs to Python files would be beneficial for Python
>>web development. I just don't see it fitting into what people here
>> have told me about WSGI.
> I suppose that Alan is moving slowly up the stack.
I'm sorry if I appear not to be as au fait with these matters as you. I
see that you've been addressing all of these problems for years with
> It's an interesting issue that existing frameworks have addressed
> in their own ways (the getRealPath that Alan mentioned, Webware's
> getServerSidePath, and so on), and although one can wonder whether
> application data (which the image example could almost be considered
> as being) should be configured within or with reference to the server
> environment or not, if you consider having to specify the filenames
> of resources within an application, it's much nicer to be able to
> make those filenames relative to some deployment variable (eg. where
> the application ends up when deployed) and to keep those resources
> bundled with the application than to have to manually configure the
> application to use absolute paths before/during/after deployment.
> I hope that made sense. ;-)
Yes, it does make sense.
To summarise: it is *sometimes* the case that static resources and the
functionality that renders them are *deployed* together, i.e. in the
directory structure, which can make for simplicity of deployment and
And as Phillip has suggested, the python module.__file__ attribute can
be used to support location of such resources.
More information about the Web-SIG