[mod_python] why is this false: 'form' in dir(req)?

Daniel Nogradi wrote ..
> > > Each mod_python request object has an attribute form (at least the
> > > ones I came accross so far), yet the following is false:
> > >
> > > 'form' in dir(req)
> > >
> > > Any reason I'm not seeing why?
> >
> > The request object is principally a C code based wrapper around the Apache
> > request_rec structure. At the same time though, it still allows adding
> of
> > attributes from within Python. None of those extra attributes however
> show
> > up when using dir(), only those corresponding to attributes in the
> > request_rec
> > structure and a few others implemented at the C code level show up. It
> is a
> > known shortcoming and probably could be fixed but no one has ever probably
> > looked at it.
> >
> > BTW, using hasattr(req, 'form') does still work.
> 
> I see, thanks. The way it turned up for me was that I wanted to
> inspect every attribute of the request object just to see what is
> there and I did this with a loop over dir(req). So what would be the
> good way to loop over every attribute (including the ones that dir
> doesn't show)?

As far as I know there isn't any way of doing it at present.

I believe that dir() works by being able to access the __dict__ attribute of
objects, but the request object doesn't have one and fudging one on the fly to
support dir() wouldn't necessarily be practical given how the request object
wrapper is currently implemented, nor would trying to have a fake dictionary of
sorts always in place as it would have to be able to cope with special
setters/getters etc.

FWIW, when SWIG is used to create Python wrappers for C code, dir() still works
and shows both underlying C struct attributes as well as Python based
attributes. In SWIG, it maintains a __dict__ attribute but it is a special fake
dictionary of sorts. One can still access attributes via __dict__ in a SWIG
object, but setting stuff in the wrapped object via __dict__ doesn't result in
the wrapped object being changed. That value is still in the __dict__ though
and accessing __dict__ direct gets back the changed value rather than that in
the wrapped object although using proper attribute access still gets value from
wrapped object. Thus, SWIG behaviour isn't perfectly correct in that case, but
then one shouldn't be accessing stuff via __dict__. :-)

Anyway, what SWIG does is academic and mod_python doesn't use SWIG but uses
hand crafted C code for its wrapper objects. 

Graham