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? --Rafael
