[Twisted-Python] Problems with PB and Jelly...

Jasper Phillips jasper at peak.org
Thu Apr 3 07:34:22 EST 2003

Hash: SHA1

On Thu, 3 Apr 2003, Glyph Lefkowitz wrote:
> On Thursday, April 3, 2003, at 05:35 AM, Jasper Phillips wrote:
> > I notice that there is a "newjelly.py" in twisted.spread, which appears
> > to have changed the code relavent to the error I was getting.  However, I
> > couldn't easily tell from the commit email whether this was finished, or
> > how one would use it...
> The way you use it is by replacing the imports at the top of pb.py and
> flavors.py to say "import jelly as newjelly" or "from newjelly import
> ...".  Please do this and see if your problem is solved.  (better yet,
> contribute a unit test so we can make sure future changes don't break
> this either...)

I just took the shortcut of replacing jelly.py with newjelly.py, as I didn't
want to hunt down imports to change.  I got several errors, and hence
wondered if it was finished, e.g.

I get this Traceback when sending from Perspective -> Client
  File "...jelly.py", line 536, in _unjelly_tuple
    if preTuple.resolvedObject is None:
exceptions.AttributeError: _Tuple instance has no attribute 'resolvedObject'

After this error I get a similar error (when sending from Client ->
Perspective) where a local variable that is set on my Perspective before
calling a "remote" client method is later missing when the client calls a
"perspective" method.

I haven't looks more closely than this though.

I posted a test case demonstrating the "circular ref" bug a couple of
messages up this thread, but didn't work out a unit test.  I'll try to get
some time to do that, although I understand twisted uses something other than
pyunit so I'm not sure what's involved.

A cursory glance at newjelly.py makes me think it can't possibly have the
same problem, as "references" and "derefences" now seem to be treated in the
same manner, and presumably your unit tests cover simple references. ;-)

> > Am I correct in guessing newjelly.py is intended to be renamed to
> > jelly.py, but isn't ready yet?
> The real issue is that this is a protocol-breaking change, and we're
> not quite prepared to deal with the fallout from that.  Brian Warner
> and I hacked on this at PyCon, and he has some ideas for backwards
> compatible version negotiation, so we may want to keep the old
> implementation around anyway.  When we figure out if and how we're
> going to do backwards compatibility, we'll make the changeover.

Isn't all the Jelly/Unjelly code pretty well encapsulated, so that others
needed really care how it works internally?

> Also, the idea behind this implementation was to simplify things so
> that some new kinds of optimizations are possible -- the implementation
> is still really grotty (though it should be functional; I've made the
> aforementioned change to my pb.py and flavors.py and the PB unit tests
> pass), and I want to make sure that these optimizations *are* actually
> made possible, and we haven't just shuffled things around for no reason
> :-)

For what it's worth (after a cursory glance), the reference/dereference
cleanup part of your changes looks like a clear improvement, but in
understandability and correctness. :-)

- -Jasper

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


More information about the Twisted-Python mailing list