[Twisted-Python] deferred as a Protocol class attribute, Protocol as class attribute of a Factory ...

[Jean Daniel]

Hello,

Reading the SMTP client tutorial[1], I do not see the impact of the
factory having a protocol defined as a class attribute. Especially
when here is a big fat warning [2] that I should actually understand
the inplications. My guess is that in this first case the protocol
methods do not need access to the protocol instance, maybe it is a
clear indication that the protocol is stateless, and there is a gain
ressource-wise since there is no instance created and maintained. But
I am not sure.

What are the implications of the protocol being a class attribute of
the factory?

Almost the same question: in the imapclient example [3], there is a
LineReceiver subclass hooked to stdio. The lineReceived callback willl
fire a callback added to an _class attribute_ deferred filled with a
user function. I think this design prevents two instances of the
LineReceiver subclass which would race on the class attribute
deferred.

What are the advantages of having defined the deferred at the class
level instead of at the instance level?

Thanks for your help,

[1]: http://twistedmatrix.com/documents/current/mail/tutorial/smtpclient/smtpclient.html#auto6

[2]: """Another minor change to note is that the protocol attribute is
now defined in the class definition, rather than tacked onto an
instance after one is created. This means it is a class attribute,
rather than an instance attribute, now, which makes no difference as
far as this example is concerned. There are circumstances in which the
difference is important: be sure you understand the implications of
each approach when creating your own factories. """


[3]: twisted/doc/mail/examples/imapclient.py in the sources and
http://twistedmatrix.com/documents/current/mail/examples/imap4client.py
on the web