Received: by 10.214.241.14 with SMTP id o14mr2098314qah.6.1219341901489;
Thu, 21 Aug 2008 11:05:01 -0700 (PDT)
Return-Path: <dangy...@gmail.com>
Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.245])
by mx.google.com with ESMTP id 39si562641yxd.2.2008.08.21.11.05.00;
Thu, 21 Aug 2008 11:05:01 -0700 (PDT)
Received-SPF: pass (google.com: domain of dangy...@gmail.com designates 64.233.178.245 as permitted sender) client-ip=64.233.178.245;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of dangy...@gmail.com designates 64.233.178.245 as permitted sender) smtp.mail=dangy...@gmail.com; dkim=pass (test mode) header...@gmail.com
Received: by hs-out-0708.google.com with SMTP id 55so56356hsc.10
for <pyke@googlegroups.com>; Thu, 21 Aug 2008 11:05:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from
:user-agent:mime-version:to:subject:references:in-reply-to
:content-type:content-transfer-encoding;
bh=xDpJtV1dOxuxAnfGMOjrS/+eXQJVT2GG2nSNjv1r2t4=;
b=VwH6W9uMLdZaVPOfGIpyyFA/RQlB0JZRDiVadBiXUHlU+8PvN7iMQjQL5hxt7qzow5
3zk+ECN7JJOnd7O4yPO6MvLsyXN+7wjkyO9/CXz1lTwWbTlkZixxXiDtw/mhcn4aeMwe
rBuEs/NMTCPJeWoGmQ7izVQJLnkc04tQEmOIk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
b=BebmlkV1SRk6s2nvQeb/o+Lh5MAQzwZluF4w7yjmUstcGUjx+vntjsfjuGT7e5k77I
XtHNDBt5sLNy+dh1QtEg2pDOT93fOJtYtMy+iaE5sunr8/JB8UTlndyBElbF7ZVCNlOI
/Jh9Tjkzo2UNgg1L+rBgyXJormYwiMvcvHr4o=
Received: by 10.100.120.15 with SMTP id s15mr70781anc.150.1219341900204;
Thu, 21 Aug 2008 11:05:00 -0700 (PDT)
Return-Path: <dangy...@gmail.com>
Received: from ?192.168.1.3? ( [24.96.120.72])
by mx.google.com with ESMTPS id c38sm411819anc.25.2008.08.21.11.04.59
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Thu, 21 Aug 2008 11:04:59 -0700 (PDT)
Message-ID: <48ADADAA.6040...@gmail.com>
Date: Thu, 21 Aug 2008 14:02:18 -0400
From: Bruce Frederiksen <dangy...@gmail.com>
User-Agent: Thunderbird 1.5.0.14ubu (X11/20080724)
MIME-Version: 1.0
To: pyke@googlegroups.com
Subject: Re: fc rules and objects - new requirements
References: <f3a3ce44-5836-4331-b31c-ee4d1bf1b...@d1g2000hsg.googlegroups.com> <27e4170c-4f56-4815-a2bb-52a05552d...@z72g2000hsb.googlegroups.com> <13b5d61a-5089-49d2-88ad-3960da128...@c65g2000hsa.googlegroups.com>
In-Reply-To: <13b5d61a-5089-49d2-88ad-3960da128...@c65g2000hsa.googlegroups.com>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
comments inlined...<br>
<br>
Good discussion!<br>
<br>
-bruce<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:egon.wuch...@siemens.com">egon.wuch...@siemens.com</a> wrote:
<blockquote
cite="mid13b5d61a-5089-49d2-88ad-3960da128...@c65g2000hsa.googlegroups.com"
type="cite">[...]
<pre wrap=""><!---->
Tracking new instances and instance changes should ideally cover
both, (a) instance creation and change by Pyke rules (using the oo
knowledge base) and (b) creation and change by the Python code
run/called by the rules.
</pre>
</blockquote>
I agree. The question is how to do this... A __setattr__ method
captures the attribute changes. But one of the problems with capturing
object creation is that you'd want the new object base to see the
created object <i>after</i> it has been fully initialized. It seems
that the least intrusive way to do this (that I can think of) is by
using Python's metaclass facility (which I've never used before!).
This would mean that all classes to be tracked by an object base be
derived from a special pyke class. That's all that the programmer of
these classes would have to do. The special pyke class would have a
__setattr__ method to trap the attribute changes and use the metaclass
capability to trap object creation after __init__ is finished. I have
attached a demo on the end of this email. It is also checked into svn
(rev 134) as pyke/metaclass.py (just to make it available to play with
-- it isn't used anywhere within pyke).<br>
<blockquote
cite="mid13b5d61a-5089-49d2-88ad-3960da128...@c65g2000hsa.googlegroups.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Then the question of how to track these object creations and
attribute changes.
I can think of two answers:
1. Modify the classes being observed to report these actions
to the new knowledge_base. This might mean, for example,
that you must derive these classes from a certain pyke class.
2. When using these new knowledge bases, expect the
programmer to go to the knowledge base to create objects and
change their attributes.
The knowledge base could accomplish these changes as well as
rerunning the appropriate fc_rules. You already suggest that
the object's attribute should be changed by asserting
"Feature.Selected($feat, True)" for example. Perhaps there
could always be a built-in "__init__" (or "__new__", or ???),
such that "Feature.__init__($feat, init_arg...)" creates an
object (and binds it to "$feat"). Then there could also be
two additional back-door methods on the knowledge_base to
allow python code to do the same things.
My initial lean would be towards the second approach. This
places more of a burden on the python code to use these new
back-door functions, but allows one knowledge base to be used
with several classes that are seen by the programmer as being
interchangeable, though they do not share a common base class
(as this is not required by python). Thus, there would be no
requirement that the name of the knowledge base match any
particular class name. That would just be up to the
programmer using the new knowledge base. (And thus, dots
('.') would still not be allowed in kb_names).
</pre>
</blockquote>
<pre wrap=""><!---->
Yes. I favour the second approach as well. Also I like the
Feature.__init__ suggestion about object creation. But somehow
one of the arguments would have to be the class instance. Or did I
miss something here?
</pre>
</blockquote>
Yes, I missed that!<br>
<blockquote
cite="mid13b5d61a-5089-49d2-88ad-3960da128...@c65g2000hsa.googlegroups.com"
type="cite">
<pre wrap="">
Using back-door methods would support the instance creation and
change case (b) from above. Ideally, what I'm even aiming at is
something like a combination of decorators and my classes in
order to reduce the burden on the python code to call these methods
when changing any attribute members or within the __init__ methods
of a class. But I'm still new to Python and I'm just thinking how
this
could work. (By the way, in C++ you should not pass an object around
until the ctor has completed. Is this the case with Python as well?)
</pre>
</blockquote>
Python does not have this problem, but we would still want the affected
fc_rules to see the fully initialized objects (the fc_rules might ask
about several attribute values).<br>
<blockquote
cite="mid13b5d61a-5089-49d2-88ad-3960da128...@c65g2000hsa.googlegroups.com"
type="cite">
<pre wrap="">
Another issue would be whether calling the back-door methods directly
or indirectly from an assert clause affects the forach clause of rules
using
the new facts. The Pyke compiler is able to build up a dependency
graph
between fc rules in order to trigger dependent fc rules with the
right
pattern bindings. But this would'nt work with the back-door methods
since it is a runtime issue. Nevertheless, I think it would be
feasible to
implement this.
</pre>
</blockquote>
The pyke compiler does not build the dependency graph. It only stores
a list of the "facts" (actually "knowledge entities") referenced in
each fc_rule's foreach clause. Then, when the rule base is activated,
each fc_rule calls <i>add_fc_rule_ref</i> on all of the listed
entities. So the new object bases would automatically get these <i>add_fc_rule_ref</i>
calls too when they are referenced by an fc_rule. This would not
require any code changes, just define the method on the new
object_base_entity objects.<br>
<blockquote
cite="mid13b5d61a-5089-49d2-88ad-3960da128...@c65g2000hsa.googlegroups.com"
type="cite">
<pre wrap="">[...]
</pre>
<blockquote type="cite">
<pre wrap="">I think that the new knowledge base tracking the instances
would pretty much do this (as explained above). But we might
also always want an "instance" (or "_instance_", or ???)
entity, such that "Feature.instance($feat)" would enumerate
the instances (i.e., succeed multiple times, binding "$feat"
to a different instance each time).
Then when a new instance is created, this would rerun any
fc_rules containing it with just the one new instance for
"$feat" so that all of the prior instances don't need to be
re-processed.
</pre>
</blockquote>
<pre wrap=""><!---->
Here we would have an implicit fact dependency between
Feature.__init__ and Feature.instance which can be resolved at
compile time. Just a remark of mine.
</pre>
</blockquote>
Again, this wouldn't be necessary. The object base will be given the
list of fc_rules that are interested in each "entity" name (for
example, "instance" and "Select"). The object base can then trigger
these rules whenever these (virtual) "facts" change. So the object
base "__init__" would know to trigger the fc_rules attached to
"instance" (for example). (Actually, I'm thinking now that the name
"create" is less confusing than "__init__" -- or maybe "__create__"?).<br>
<br>
----------------- cut here for metaclass.py demo ---------------------<br>
<tt># metaclass.py<br>
<br>
from pyke.unique import unique<br>
<br>
class metaclass(type): # this _must_ be derived from 'type'!<br>
_ignore_setattr = False<br>
def __init__(self, name, bases, dict):<br>
# This gets called when new derived classes are created.<br>
#<br>
# We don't need to define an __init__ method here, but I was
just<br>
# curious about how this thing works...<br>
print "metaclass: name", name, ", bases", bases, \<br>
", dict keys", tuple(sorted(dict.keys()))<br>
super(metaclass, self).__init__(name, bases, dict)<br>
def __call__(self, *args, **kws):<br>
# This gets called when new instances are created (using the
class as<br>
# a function).<br>
obj = super(metaclass, self).__call__(*args, **kws)<br>
del obj._ignore_setattr<br>
print "add instance", obj, "to", self.knowledge_base<br>
return obj<br>
<br>
class tracked_object(object):<br>
r'''<br>
All classes to be tracked by an object base would be derived
from this<br>
one:<br>
<br>
>>> class foo(tracked_object):<br>
... def __init__(self, arg):<br>
... super(foo, self).__init__()<br>
... print "foo.__init__:", arg<br>
... self.x = arg # should be ignored<br>
metaclass: name foo , bases (<class
'__main__.tracked_object'>,) ,<br>
dict keys ('__init__', '__module__')<br>
<br>
<br>
And we can keep deriving classes:<br>
<br>
>>> class bar(foo):<br>
... def __init__(self, arg1, arg2):<br>
... super(bar, self).__init__(arg1)<br>
... print "bar.__init__:", arg1, arg2<br>
... self.y = arg2 # should be ignored<br>
metaclass: name bar , bases (<class '__main__.foo'>,) ,<br>
dict keys ('__init__', '__module__')<br>
<br>
<br>
We can't do the next step directly in the class definition
because the<br>
knowledge_engine.engine hasn't been created yet and so the
object<br>
bases don't exist at that point in time.<br>
<br>
So this simulates adding the knowledge_base to the class later,
after<br>
the knowledge_engine.engine and object bases have been created.<br>
<br>
>>> foo.knowledge_base = 'foo base'<br>
>>> bar.knowledge_base = 'bar base'<br>
<br>
<br>
And now we create some instances (shouldn't see any attribute
change<br>
notifications here!):<br>
<br>
>>> f = foo(44)<br>
foo.__init__: 44<br>
add instance <__main__.foo object at 0x...> to foo base<br>
>>> b = bar(55, 66)<br>
foo.__init__: 55<br>
bar.__init__: 55 66<br>
add instance <__main__.bar object at 0x...> to bar base<br>
<br>
<br>
And modify some attributes:<br>
<br>
>>> f.x = 'y'<br>
notify foo base of attribute change:<br>
(<__main__.foo object at 0x...>, x, y)<br>
>>> b.y = 'z'<br>
notify bar base of attribute change:<br>
(<__main__.bar object at 0x...>, y, z)<br>
>>> b.y = 'z' # should be ignored<br>
>>> b.z = "wasn't set"<br>
notify bar base of attribute change:<br>
(<__main__.bar object at 0x...>, z, wasn't set)<br>
<br>
'''<br>
__metaclass__ = metaclass<br>
_not_bound = unique('_not_bound') # a value that should != any
other value!<br>
def __init__(self):<br>
self._ignore_setattr = True<br>
def __setattr__(self, attr, value):<br>
# This gets called when any attribute is changed. We would
need to<br>
# figure out how to ignore attribute setting by the __init__<br>
# function...<br>
#<br>
# Also the check to see if the attribute has actually changed
by doing<br>
# a '!=' check could theoretically lead to problems. For
example this<br>
# would fail to change the attribute to another value that
wasn't<br>
# identical to the first, but '==' to it: for example, 4 and
4.0.<br>
if getattr(self, attr, self._not_bound) != value:<br>
super(tracked_object, self).__setattr__(attr, value)<br>
if not hasattr(self, '_ignore_setattr'):<br>
print "notify", self.knowledge_base, \<br>
"of attribute change: (%s, %s, %s)" % (self,
attr, value)<br>
<br>
def test():<br>
import sys<br>
import doctest<br>
sys.exit(doctest.testmod(optionflags = doctest.ELLIPSIS<br>
| doctest.NORMALIZE_WHITESPACE)<br>
[0])<br>
<br>
if __name__ == "__main__":<br>
test()<br>
</tt><br>
</body>
</html>
Message from discussion fc rules and objects - new requirements
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |