[Twisted-Python] making twisted provide good feedback (was Re: Having reactor run at the main thread...)

Jonathan Lange jml at mumak.net
Fri Nov 7 05:30:43 EST 2008

On Thu, Nov 6, 2008 at 9:22 PM,  <glyph at divmod.com> wrote:
> (Moving this off the twisted-web list because it is of more general interest
> and contains nothing web-specific.)
> On 09:48 am, jml at mumak.net wrote:
>> On the other hand, there's a related invalid argument that gets used a
>> lot by library and framework authors: "if we provide X, people might
>> misuse it, so we should not provide X". This argument is also bogus
>> (that way lies Java). Provide safe, well-documented alternatives for
>> the abusers and let those who want to shoot themselves in the foot do
>> so: sometimes they might actually know better than you.
> I find it peculiar that you think this is Java's disease.  My perspective is
> that Java is unpleasant because it is remarkably tedious, redundant, and
> inconsistent, not because it lacks functionality.  If anything, it's a mess
> of functionality, and there are too many ways to do the same thing.

I was thinking of operator overloading and multiple inheritance,
actually. The rationale for not including them in the language was
that they are often abused. {{fact}}

> Twisted should provide excellent support for valid use-cases, no matter how obscure.


> On the other hand, it's equally frustrating to use a library where the
> incredibly obscure "you probably don't need this" and the 99%-of-the- time
> positive-path APIs are listed, without any particular ordering, in one giant
> flat list.

Yes. This is a documentation (or perhaps a navigation) problem. I
simply wanted to make the point that I find "don't provide X because
people might abuse it" unconvincing. I don't even think you were
making that point, but I really really want to be clear that it's not
a good one.

Also, if you haven't read it, you might enjoy Rusty's interface guide:


More information about the Twisted-Python mailing list