On 07:54 am, sank.dan...@gmail.com wrote:
I have a project in which various modules need to import a particular
module "util" which has the following content:
# util.py
class FooMaster(pb.Cacheable):
...
class FooSlave(pb.RemoteCache):
...
pb.setUnjellyableForClass(FooMaster, FooSlave)
Module "server" lives in the same directory as util and imports it like
this
# server.py
import util
Module clent lives in an entirely different directory and imports util
like
this
# client.py
import myproject.path.to.some.files.util as util
This leads to the infamous insecureJelly exception because the name of
the
FooMaster class winds up being different due to the different import
statements. Specifically, server's copy of pb registers it as
"util.FooMaster"
but client's copy registers it as
"myproject.path.to.some.files.util.FooMaster"
1. Is it a bug that pb cares about how something was imported when
registering unjellyable classes?
No. It's a bug in your application. ;)
2. If not, how am I supposed to work around this?
Always refer to modules in the same way. Never use relative imports.
3. The problem goes away if I use the long, fully qualified import
statement everywhere. Is that what I'm supposed to do?
Yep!
If you really had different classes on the client and the server
representing the same abstract entity then you could explicitly register
them as being related by registering them using a name instead of using
a class object. When you pass a class object, pb just computes that
name for you.
However, you don't really have different classes here: just differently
named copies of the same class. Consistently importing the class using
the correct, fully qualified package name will cause the classes to have
the same name (and, if you load the client and server in once process,
will cause only *one* copy of the module and class to be loaded, rather
than two) and fix the PB issue.
Jean-Paul
I read the howto and the on Stackoverflow question I could find
regarding
this issue. In both cases, it says to not define names in a main file
precisely to avoid this issue, but not what to do in my case.
Thank you for any advice.
--
Daniel Sank
Department of Physics
Broida Hall
University of California
Santa Barbara, CA 93117
(805)893-3899
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
