[Twisted-Python] Components

[Bob Ippolito]

On Feb 26, 2004, at 6:51 PM, Christopher Armstrong wrote:

> Glyph Lefkowitz wrote:
>> And of course, integrating foom's string-based components would be 
>> great
>> too.  There is a lot of friction even to add something like this to
>> Twisted.  I imagine that adding something like this to PyProtocols, 
>> with
>> potentially more projects out there depending on the exact specifics 
>> of
>> all its semantics, would be even worse.
>
> Well, Bob said in another message that he had already done 
> string-registration of adapters successfully. (?)

Here's an example:

from protocols import *
import peak.utils.imports as imports
# does not depend on other PEAK stuff.. can easily be stolen

mxDateTime = imports.lazyModule('mx.DateTime')
datetime = imports.lazyModule('datetime')
def _hook_mx_DateTime(mxDateTime):
     declareAdapter(
         NO_ADAPTER_NEEDED,
         provides=[IBasicDate],
         forTypes=[mxDateTime.DateTimeType],
     )
     #datetime = imports.lazyModule('datetime')
     def convertToDateTime(obj, protocol):
         msec, second = math.modf(obj.second)
         # handle tzinfo ?
         return datetime.datetime(
             obj.year, obj.month, obj.day,
             obj.hour, obj.minute, int(obj.second),
             int(msec * 1e6), None
         )
     declareAdapter(
         convertToDateTime,
         provides=[IBasicDateTime],
         forTypes=[mxDateTime.DateTimeType],
     )
imports.whenImported('mx.DateTime.mxDateTime.mxDateTime', 
_hook_mx_DateTime)

def _hook_datetime(datetime):
     declareAdapter(
         NO_ADAPTER_NEEDED,
         provides=[IBasicDate],
         forTypes=[datetime.date],
     )
     declareAdapter(
         NO_ADAPTER_NEEDED,
         provides=[IBasicDateTime],
         forTypes=[datetime.datetime],
     )
imports.whenImported('datetime', _hook_datetime)

This could of course be automated a bit more, and there is probably 
even a better way.. but this was the first thing I stumbled across 
without thoroughly reading documentation or asking anyone :)

>> The other alternative is to add a bunch of specific hacks to 
>> PyProtocols
>> that get loaded only when Twisted gets loaded, which could potentially
>> introduce compatibility problems with other PyProtocols-using code,
>> which would sort of invalidate the whole point of using a common
>> components system in the first place.
>
> My previous retorts make this point of yours irrelevant for the 
> moment, so I will not respond: if you want, you may debate my retorts 
> and we can get to this point once we have worked those out.[1]
>
> [1] I need to figure out a succinct way to say this. Maybe some Latin 
> crap. It's way too verbose. spiv suggested "ad nauseum" when I asked 
> him... Better look that one up. ;-)

PyProtocols really is flexible enough to accommodate whatever.

>> Then we have the issue of the PyProtocols dependency; dependency
>> management can be quite hairy on windows.
>
> Hmm, yeah, I assumed we would include our own (hopefully unhacked) 
> copy of PyProtocols in releases.

I would suggest including it beside, not inside, Twisted.  The setup.py 
could check to see if a newer version is already installed, too.

>> Maybe I'm alone in these concerns, though.  Does anyone else feel that
>> depending on PyProtocols would increase the learning curve for Twisted
>> even more?  Or is this common knowledge in the Python community that
>> could be leveraged to actually make the curve shallower?  I can
>> certainly learn to wrap my head around the whole thing if nobody else
>> has trouble with it :)
>
> I kinda hold this reservation. PyProtocols is VERY complex compared to 
> the t.p.c components system. But maintaining our own inadequate 
> version is pretty sucky.

Well my first and last significant experience with a t.p.components 
based project:
== start using t.p.c ==
- Why AREN'T adapters transitive?
- How do I expose an interface that the *class* provides?
- Oh, I *can't do that*, I guess I'll have to patch t.p.c.
- Grudgingly write software on top of patched t.p.c.
== t.p.c gone forever ==
- Rewrite the code on PyProtocols.  It's a lot shorter and cleaner, 
even though I do use adapt(..., IFoo) instead of IFoo(...).
- Still haven't found a use case that PyProtocols can't already do.
- Started looking at PEAK, it solves most of the other problems I have 
(lazy imports, bindings, data modeling, etc.)
- .. hoping Twisted starts assimilating PEAK stuff, because it's better 
:)

>>> There might be some other issues that could come up, but I'm 
>>> definitely willing to try to "adapt" to Twisted's needs in these 
>>> areas, especially if it means I could get rid of PyProtocols' 
>>> wrapper code and wrapping tests for Twisted's existing interface 
>>> class.  :)
>> This is clearly something that we need to talk about more.  As many
>> silly disagreements about design as I can come up with, a common
>> components system would be beneficial to everyone involved.  Are you
>> coming to PyCon? :)
>
> PyCon! PyCon! Everybody come to PyCon!

I'm there!

-bob