> Maybe you've got bigger things in mind, but I don't know what all of > that buys you, at least from your example use case (client connects, > prints response from server, quits on 'stop'). What's wrong with keeping > it simple and handling responses in the Protocol? > > def lineReceived(self, line): > if line == 'stop': > reactor.stop() > else: > print(line)
I think it buys a bit of simplicity if the ClientCreator is called and all handy methods are attached to the protocol argument of the callback. For the code that you show, there is a need to import the right package and the right base class, name a class, override a method. So, it does not buy much, actually. More importantly IMHO, in your example the code embeds the knowledge of the protocol strings. In some context, it is useful to hide it behind an API to spare the developers the reading of the RFC, or in others context, the wire protocol might change while the API stays stable. Cheers, > > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
