Twisted huh?
One of the hallway conversations I've had a few times so far at EuroPython goes like this:
A: Twisted's got some good stuff going for it, but I don't like the way it forces me to use Zope interfaces. It's too heavyweight?
B: Huh? What do you mean? It doesn't make you do that.
C: Yeah, there's lots of deep inheritance, which just feels really wrong.
A: Right, I have to write too much code to get something simple working.
B: Sorry, I have no idea what you mean. Can you give a concrete example?
A, C: I can't think of one right now.
To me, this is a very intriguing beginning to a real conversation. Do you know what A and C might mean here? I'd love to understand their points so that I can form an opinion.
posted by jml @ 1:18 AM
9 Comments
9 Comments:
If only we *could* force them to use zope.interface. ;-)
I like Twisted.
But, I know where people are coming from. You get a bunch of docs that just don't seem to quite fit together and the API reference just doesn't seem quite finished, so your learning process is scattered all over the place.
So you read a tutorial and you get told you have to write 10 lines of code, except you only know what 1 of those lines actually does. The rest is just "necessary", but since you don't know what it does, it's easy to see why people think it's unnecessary boilerplate, when in fact it's a bunch of powerful tools that you can use to extend your application.
I really believe that the only thing that creates such an unexpected number of Twisted detractors is the fact that there isn't a nice, easy, pretty, consistent documentation system that takes each part of Twisted as a clean slate, providing easy access to all the core stuff that's being used in the examples as assumed knowledge.
Once the assumed knowledge is clearly laid out and accessable from every page I think everything will fall into place.
Learning a new API, especially one as extensive as Twisted's, is hard enough already, without also having to juggle in your mind a kludgy and patchy documentation system.
(I really, really do like Twisted a lot though)
"B" said. Twisted's just too impenetrable for newbies. As a seasoned Twisted programmer (ie. I've written a few systems using it) I'm still not sure where to look in the docs for simple things like the API for deferreds and how they work.
The inheritance tree is part of this: the API docs for a lot of classes just indicate that they inherit from some other class(es) and add some (un- or poorly-documented) new methods. To find out how to use said class you have to dig right down to the base class(es) and often their documentation is also poor/missing/too abstract.
This post has been removed by the author.
ps. I also like Twisted ;)
I think it would be a lot easier to understand Twisted if it was smaller. I don't mean remove features, but rather reduce cases where it duplicates functionality from the standard library.
For example, if I am trying to understand the deferred concept, I need to understand failures. I already understand exceptions, but now need to learn about this similar but slightly different concept.
For each of the bits of twisted.python where standard library interfaces have been extended, it would be good to consider them bugs that should eventually be fixed by getting the standard library updated. For failures, perhaps the exception handling changes in Python 3 are enough to use directly.
In other cases, I think it would be useful to look at pushing some of Twisted's core concepts into the standard libraries. The deferred system is one I've mentioned before. The API review that would come it would likely be helpful too.
For me the biggest issue with Twisted is the steep learning curve. It isn't helped by the documentation - although the twisted book goes some way to dealing with that. Most of what I know about Twisted I learned from the source code though.
I wrote a large heavy duty crawler in it - including custom DNS and HTTP protocols. And if I was honest I am still not 100% sure how the protocol/factory bits work although I obviously have made them work well (because the crawler worked really well)
Not sure what or even if you would want to do something about this. Twisted is incredibly powerful and can do some superb stuff - but on the other hand I am unlikely to start new projects with it because either I maintain it or I have to push team members up that learning curve before they can do anything on it.
I keep hearing things like this as well, and I just don't understand why so many are so intimidated by twisted. It really isn't any harder to get to grips with than any other large python project like TG IMHO. They do have some tools to kick you into gear a little faster perhaps.
I also hear things like "twisted eats your errors", "twisted doesn't let me use threads", "twisted can't work with my libraries", "you can't use databases with twisted" - all utter nonsense, but I keep hearing it over and over again. They're usually in the form of anecdotal stories "twisted ate all my errors, I promise I attached errbacks".
Some 5 minute howtos may be the answer to some of these. If we listen to a few of these complaints and create a "how to access your ${foo}sql instance", "how to set up logging", "how to use callInThread/callFromThread", "why forgetting your errbacks is bad" it could be something to point folks to.
Kilroy, I think you need to read the comments already posted here (maybe again, but reading your reply I can't help thinking for the first time).
In particular, about HOWTOs "B" specifically said "So you read a tutorial and you get told you have to write 10 lines of code, except you only know what 1 of those lines actually does."
Without solid API documentation to back them up those HOWTOs are basically just crumbs thrown out to try to satisfy the hungry masses.
Post a Comment
<< Home