bob at redivi.com
Thu Feb 26 19:39:01 EST 2004
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
>> too. There is a lot of friction even to add something like this to
>> Twisted. I imagine that adding something like this to PyProtocols,
>> potentially more projects out there depending on the exact specifics
>> 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')
#datetime = imports.lazyModule('datetime')
def convertToDateTime(obj, protocol):
msec, second = math.modf(obj.second)
# handle tzinfo ?
obj.year, obj.month, obj.day,
obj.hour, obj.minute, int(obj.second),
int(msec * 1e6), None
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
>> 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.
>  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
== 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!
More information about the Twisted-Python