[Twisted-Python] How to force synchronous behavior

[Jean-Paul Calderone]

On Mon, 31 Oct 2005 00:02:47 +0200 (SAST), Clive Crous <clive at darkarts.co.za> wrote:
>#>Why do i hit this wall constantly when discussing twisted usage with
>#>twisted users or developers mostly on freenode's #twisted admitedly:
>#>Telling someone NOT to do something is not answering a question it is
>#>avoiding it.
>#
> [snip]
>#
># I have adopted this stance not merely because I am abraisive asshole, but
># based on long experience with IRC and with teaching programmers how to use
># things.  There are several projects that were developed early on with
># Twisted that were utter disasters because I politely and pateiently
># answered all the authors' questions about how to make Deferreds appear to
># block, how to call reactor functions from threads, and how to invoke
># Twisted from C code, rather than stopping and saying "hey, what are you
># *really* trying to do?".  (No, I will not name these projects.  I do have
># *some* manners.)
>#
># I can only assume that the other Twisted devs you've had problems with
># have gotten this habit from similar experiences, but they may have their
># own reasons.
>#
>
> [snip]
>
>If I come online, and ask: "How do i use A with B" and the response is
>"Dont!", as in this thread, it shows a high level of arrogance, extreme
>presumption and an incredible 'naivety to programming' by the person
>giving that "answer".

I find it equally arrogant to expect the community to behave in the way you would prefer.  What is owed to you that justifies this, exactly?

>There always will be people who have different needs to you.
>Enforcement of usage policy on users is the realm of restrictive
>corporate use policy and software distribution licensing as one expects
>from Microsoft et al.

First of all, no one is forcing anything on you.  You're not locked in.  Don't use Twisted if you don't want to.  Don't use Twisted in the manner we are explaining is correct if you don't want to.  Fork Twisted and take development in a better direction.  Rip parts of Twisted out and drop them into your own project to use how you please.  Spit on our works.  Curse our names and our progeny to the seventh generation, if that's your thing.  Who's going to stop you?  Not me, and not anybody else on this list.

I recognize that you probably don't want to do any of these things.  You want to keep using Twisted, and you want the Twisted team to do things your way.  I have this same expectation of other projects.  Let's face it: it's an unreasonable expectation. 

Twisted is developed for you by a team of uncompensated developers working in their spare time.  Likewise, support is being offered for free.  It should not be too surprising that it is also being offered *conditionally*.  A lot of us are happy to help with problems that don't directly benefit us, but a lot of us are not happy to help with solutions that we think are just as problematic as that which they are intended to resolve.  Are you going to fault us for limiting the extent of our unpaid donations (frequently to commercial development)?  Please.

Furthermore, a perfectly legitimate response to "Don't!" is "But I have constraints X, Y, and Z."  You may feel it is unreasonable to explain your situation, but that's pretty much too bad for you.  If you want to be able to dictate people's behavior to this extent, negotiate a contract with them.  Now, we may not be convinced by constraints X, Y, and Z, but in most cases where they are rational and correct (ie, not "I have to use threads because Cthulhu will rise and consume the world if I do not" - although if you are working on the project to prevent this, and are using Twisted, awesome!  Can we put you on the successes page?), we will be.  It is the refusal to explain them at all that is most annoying, and most likely to result in no assistance being rendered.

I don't think this attitude is unique to the Twisted community.  I don't even think it is unique to open source communities.  Nor do I think it is a negative attitude.  I think it is more open minded and generally productive than just presenting the precise answer to each exact question posed.  In many cases, I have concrete evidence that not answering a direct question with a superficially correct response has helped the questioner measurable, and I've been thanked for this approach repeatedly.

>I have worked with programmers who hold the same mind-set as is being
>shown here.
>Some of the "programmers" with whom I have worked in the past, were insistent
>that things should be done in a particularly restrictive, stylized manner and
>that no-other-way-is-the-right-way.

This is a mischaracterization of the attitude I use when trying to help people, and from what I've witnessed of the interactions of other members of the Twisted community, I think it is not representitive of their behavior either.

The interaction that gives rise to this impression, in my experience, most typically involves much more adament insistence and inflexibility on the part of the person seeking help than on the part of the person from which help is sought: the questioner *knows* they are already on the right track, and if this jerk he is talking to would just stop asking questions and answer them for a change, the problem would immediately be solved.

>There is *NO* absolute "right way" when it comes to coding.  There are
>good ways
>and bad ways however all are dependent on the context of the project at hand
>and it's particular specifications.

Which is why I stress the importance of discussing the context of a problem before trying to resolve it.

>The most common result of such narrow-minded
>programming mind-sets is the inability to complete the task at hand.
>Programs will be written, rewritten, re-factored, tossed out and
>restarted.  This cycle will never end as long as this zenith of coding
>"nirvana" remains the goal.  The tragic result of this is that
>projects repeatedly fail to reach a usable state, to the detriment of
>all.

Twisted comes with a news server, a mail server, a chat server, a chat client, a remote REPL with multiple front ends, a plugin system, numerous persistence systems, a documentation framework with multiple input and output formats, an "Application" abstraction, an SSH client, an SSH server, an authentication and authorization system, a mature TCP, UDP, and SSL client and server API with numerous implementations for numerous platforms, an asynchronous DB-API 2.0 wrapper, an inetd-alike, a high-level remote method and object protocol, a unit test framework and rich command line tool for interacting with test suites, a web server, a web client, a DNS server, a DNS client, and FTP server, an FTP client, implementations of the echo, discard, chargen, ident, finger, QOTD, who, daytime, time, telnet, sip, toc, and oscar protocols, a filesystem path abstraction, a threadpool implementation, a much higher-quality module reloading system than the builtin reload(), a logging system, and quite a few other mature, stable features.

Arguing that the Twisted team cannot complete tasks is ridiculous.

>I hope twisted development does not go down this path and shows
>some maturity and the ability to sustain it's own usage.  I really
>do love the twisted framework and would hate to see it dragged into a
>quagmire of self-indulgent disarray to the despair of a dedicated and
>loving user base (whom you freely admit not to care about at all).

Twisted has been driven by hate for a long time.  Hate and shared goal of the team to destroy the sun.  There's no change in direction going on, at least with regard to the fundamental drive directing Twisted's development.

Jean-Paul