----- Original Message ----- > From: "Rafael Schloming" <r...@alum.mit.edu> > To: proton@qpid.apache.org > Cc: us...@qpid.apache.org > Sent: Wednesday, December 11, 2013 9:43:59 AM > Subject: Re: Python wrapper - SASL and SSL class API > > On Wed, Dec 11, 2013 at 9:35 AM, Ken Giusti <kgiu...@redhat.com> wrote: > > > > > Hi all - just wanted to get some opinions on $Subject: > > > > While I was trying to implement a fix for > > https://issues.apache.org/jira/browse/PROTON-476 I found that the > > lifecycle model for the python SASL and SSL objects differs for the C > > engine. I think the python wrapper's impl is buggy. > > > > In the C engine, these objects are singletons with respect to their > > associated transport - there can only be one SSL and SASL object associated > > with a given transport. This is enforce by the C api - the transport > > provides factory classes for these objects. > > > > The python wrapper doesn't enforce this. For both objects, a "public" > > constructor is supplied (I say "public" because it is exported by the > > wrapper's __all__ list). This makes it trivial for an application to > > construct multiple instances of SASL/SSL objects that reference the same > > underlying C object. While this can technically be done safely using > > reference counting, I think it may lead to unanticipated behavior - not to > > mention that it differs from the object model provide by the C engine. > > > > I'd like to fix this by modifying the python wrapper to remove the SSL and > > SASL objects from the __all__ list, and provide factory methods on the > > Transport class for creating instances of these objects. > > > > This would result in a change to the public API. > > > > Why exactly do you need to change the API to do this? I would expect there > should be a number of ways to keep it the same, e.g. rename the class and > use a factory function with the same name as the class, or override __new__ > if you want to keep the class name the same. Am I missing something? >
Ah - actually, you've reminding me that there isn't a reason to change the api! It should be possible to create a method using the the existing class name, eg: def SASL(transport): return existing SASL associated with transport, or new one if none and rename the SASL class itself: class _SASL(object): ..... Thank you - always helps to have a firm grip on the capabilities of the language you're working with :) > --Rafael > -- -K
