[PEAK] peak.naming question

Andy Gross andy at andygross.org
Tue Dec 21 23:24:05 EST 2004

I'm really liking peak.naming so far.  I've been subclassing from 
GenericPathURL and registering in peak.naming.schemes, which has 
allowed me to toss out a bunch of bug-ridden legacy config parsing 

I'm at a point where I can get rid of a bunch of subclasses that only 
differ in their getObjectInstance implementation.  Each naming scheme 
allows for abbreviations in the "host" portion of the URL.  In the 
example URL "someproto://foo", "foo" references a set of configuration 
properties protocols.someproto.servers, and getObjectInstance (by 
default) should return a random choice out of that set.  I've pasted 
some example code below to illustrate.

I'd like to implement the server-picking functionality in some place 
other than the actual object who's class implements getObjectInstance - 
I'm just not sure if it should be done in the URL subclass, or if I 
should need to make a context subclass for the resolution process.  I 
suppose there are a number of ways to implement this, but I'm curious 
as to the idiomatic/proper way to do it.


     def getObjectInstance(klass, context, refInfo, name, attrs=None):
         self = klass(context.getParentComponent(),
         return self

Subclasses (which I'm trying to eliminate):

     def getObjectInstance(klass, context, refInfo, name, attrs=None):
         self = super(IRCPresence, klass).getObjectInstance(context, 
refInfo, name, attrs)
         self.server = random.choice(self.servers[name.host])
         return self



More information about the PEAK mailing list