[Zope] type(sql_search())?

[Chris McDonough]

It's likely an instance of a "record" object (as defined in
lib/Components/ExtensionClass/src/Record.c).  I believe the idea for it
not having a __dict__ (snicker) was that there can be many, many of
these generated for a single SQL query and thus it saved memory at some
point in time.  I'm not sure how true that is now.  It may still be
eminently so.  They don't have a __dict__ but they are enumerable. 
Something like this might work (or something along these lines, I have
not tested it):

class my_wrapper:
    def __init__(self, sqlres):
        d = {}
        for k in sqlres.__record_schema__.keys():
            d[k] = getattr(sqlres, k)
        self.__dict__.update(d)
        my_form = DTMLFile('www/my_form', globals())

    def some_method(self, foo):
        return self.sql_stuff + foo

wrapped_results = [my_wrapper(r) for r in sql_search()]

In any case, I'm not sure what you mean about type() not working against
them.  I can see their type fine including class and module name if I
instantiate one from a Python prompt (to do so is a bit cumbersome
because it means you must give it a __record_schema__ attribute,
typically just for test purposes an empty dictionary, but it does work).

If you mean that you can't see their type from a Python Script or DTML
or somewhere, the type builtin is not accessible due to security
constraints (this is a FAQ).  If you mean that this is from "trusted"
code like a Product, and its repr just doesn't render in your browser,
it's because you're viewing the rendering of the error as an HTML page,
the repr is between pointy brackets, and your browser just won't show it
to you because it thinks it's part of the HTML.  View the source of the
page instead, or use Zope 2.6 and learn to use the error_log feature.

- C


On Mon, 2002-12-09 at 00:34, Terry Hancock wrote:
> Can anybody tell me what this mysterious "results object" thing actually is?
> 
> I'm working from within a Zope product, and defining an SQL() method
> (same as "ZSQLMethod" created within the ZMI). I then call the method
> and get a "list of results". Okay, that's a list, but what are its elements?
> 
> Aren't they "class instances"?  Why don't they have a __dict__?  What *is*
> this beast, and why isn't it something simple?
> 
> I was actually trying to forgo the ridiculously cumbersome path of defining
> a "pluggable brain" with module and class name and passing it to the
> "advanced management" interface of my ZSQLMethod -- i.e. pretending I'm doing 
> everything through the web.  It seems like that really ought not to be 
> necessary in product code. You ought to be able to just slap the wrapper on 
> right in the code, without setting up all that boilerplate, e.g.:
> 
> class my_wrapper:
> 	def __init__(self, sqlres):
> 		self.__dict__.update(sqlres.__dict__)
> 		my_form = DTMLFile('www/my_form', globals())
> 
> 	def some_method(self, foo):
> 		return self.sql_stuff + foo
> 
> wrapped_results = [my_wrapper(r) for r in sql_search()]
> 
> However, that "sqlres.__dict__" chokes, because, mysteriously, sqlres doesn't 
> have one. I've had a look at RDB.py, and it sure looks like it ought to have 
> __dict__, but experimentation says no.
> 
> I thought I'd just run type() on it, and see what Python thinks it is, but 
> that brings up another pet peeve about Zope: Why doesn't type() work 
> correctly in Zope? Or rather, why doesn't it have a repr()?  Running 
> debugging code like:
> 
> raise ValueError("My type is %s!" % repr(type(buggy_object)))
> 
> returns a Zope traceback page which says:
>     Error Type: ValueError
>     Error Value: My type is! 
> 
> >From the Python command line, of course, this will tell me what the type of 
> the object is, such as:
> 
> >>> raise ValueError("%s" % type(a))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: <type 'class'>
> 
> but not in Zope.
> 
> Any help would be much appreciated!
> Terry
> 
> --
> Terry Hancock ( hancock at anansispaceworks.com )
> Anansi Spaceworks  http://www.anansispaceworks.com
> 
> "Python takes the pain out of programming ...
>             ... and Zope puts it back again."
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )