MIME-Version: 1.0
Received: by 10.151.158.2 with SMTP id k2mr390091ybo.12.1231613800125; Sat, 10 
	Jan 2009 10:56:40 -0800 (PST)
Date: Sat, 10 Jan 2009 10:56:40 -0800 (PST)
In-Reply-To: <d73de7a0-2643-4177-a53c-4543d81a42a7@a26g2000prf.googlegroups.com>
X-IP: 24.96.120.72
References: <d73de7a0-2643-4177-a53c-4543d81a42a7@a26g2000prf.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) 
	Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5,gzip(gfe),gzip(gfe)
Message-ID: <f964dfa6-a34b-412c-b610-f35659d278f1@z27g2000prd.googlegroups.com>
Subject: Re: Refactoring PyKE
From: dangyogi <dangy...@gmail.com>
To: PyKE <pyke@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Jan 9, 5:05=A0pm, Jeremy <jeremy.mcmil...@gmail.com> wrote:
> Integrating PyKE into Zope, and indeed paving the way for more
> flexible persistence, probably first requires factoring out the
> filesystem dependent code into separate routines. I think it might be
> time to cut a branch.

I am glad that you are excited about this, but there are only a total
of 7 calls to the built-in "open" function in all of the PyKE source
code that need to be looked at:

- 3 calls in pyke/krb_compiler/k*parser.py to open the 3 kinds of
source files (.krb, .kfb and .kqb)
- 3 calls in pyke/krb_compiler/__init__.py to write .py, .fbc and .qbc
files, and
- 1 call in pyke/knowledge_engine.py to open .fbc and .qbc (pickle)
files.

Each of these is rather trivial to change.

I don't think that we are quite ready to start a branch yet.  And
besides, an error has been reported that is ending up touching a lot
of this code dealing with files that hasn't been committed yet.  So it
might be better to wait a few more days.  OTOH, if you really want to
start immediately, I can create the branch now and then you can merge
the bug fix changes into the branch later.  Let me know.

> My plan-A would be to develop the branch so that all non-Zope specific
> changes to the PyKE codebase could easily be merged back into the
> trunk, and the Zope specific stuff would exist as separate files. The
> code that handles files would sit alongside the Zope stuff, and maybe
> we want to get pedantic and implement a third storage method.

I plan to branch the whole trunk (including the documentation, unit
tests and examples).  While the Zope work is ongoing, changes on the
trunk can be merged into the branch (luckily, subversion 1.5 makes
this much easier and SourceForge is using 1.5 svn servers -- you'll
need to make sure that you have a 1.5 or later svn client).

Then when the Zope work is done, we can merge the entire branch back
into trunk.  This should put everything back together in one place.

I envision that the Zope work would then be included in all PyKE
releases from that point on.  There may be a pyke/zope directory that
isn't used by "Plain-PyKE" users, but is still part of the release.
My assumption here is that the pyke/zope stuff would not grow the PyKE
release by more than about 50%.  If the pyke/zope stuff turns into a
monster, then we may need to find a Plan B.

So the merge of the branch back into the trunk at the end would bring
the pyke/zope directory into the trunk.

Does this make sense?

One another topic --- Do objects destined for the ZODB need to be
derived from some kind of zope.persistent class?  And, if so, can this
be done by multiple inheritance:

pyke/knowledge_engine.py:
    class engine(object):
        ...

pyke/zope/knowledge_engine.py
    import pyke.knowledge_engine

    class engine(zope.persistent, pyke.knowledge_engine.engine):
        ...