[Twisted-Python] How to force synchronous behavior

[Clive Crous]

#>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.
#
# You are correct.  I do not disagree with this fact, and it does not change
# my opinion of the behavior involved.  Here is the ugly truth of the
# non-answers to such questions:
#
# I do not care about most of the posters to this list.  I am happy that
# they use Twisted, and even more happy if they are pleased by it, but
# ultimately I am really just trying to improve the world I live in, and
# that means the average quality of available Python code.  That means I am
# only going to answer questions which I believe will contribute positively
# to the state of affairs as it regards code quality in general, and Python
# code quality specifically.
#
# These people who people whose questions are answered (or not answered) on
# this list or on IRC will go and write applications or libraries based on
# the answers they receive.  I may be stuck maintaining or using that code
# at some point.
#
# Now, maybe if I know, but don't tell them how to do some ridiculous thing
# they're trying to do, they'll miss their deadline at work or they won't
# turn on their homework assignment on time and I could have prevented that.
#  They will be unhappy.  Making them happy isn't my purpose here, so I
# don't care.  Maybe they'll abandon their Python project and do it in Ruby
# instead because the Python community is so hostile.
#
# Many people think that this loss of contributing labor is a great tragedy
# for an open-source community, but IMHO it is really the best possible
# consequence.  All the people who don't understand programming will end up
# in the more-polite Rails or PHP or Django or TurboGears communities and
# generate huge piles of code that don't work.  Then all the guys who know
# what they're doing will stick around here and work on Twisted stuff.  In
# the sense that we compete with those projects, this is great!  It's like
# sabotage-by-proxy.  When those projects are a smouldering ruin of
# inconsistent style and half-baked, buggy, insecure code, people who want a
# functional product will come ask those of us with Twisted expertise.
#
# A more realistic consequence, however, is that programmers new to Twisted
# will adopt a more consistent style, and avoid fighting the framework, and
# concentrate on solving their actual problems.  Some will still go away,
# yes, but generally there is some reason they came to Twisted in the first
# place and it remains valid even if we won't make it easy to do things we
# collectively regard as bad practice.
#
# 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.
#

I find it quite amusing, yet somewhat disturbing how you justify this
behaviour to yourselves.  I have worked on many projects in my life and
each of them was unique in it's specific requirements.  Let me give you
two of my current projects as brief examples:

The first, is for a client who would like a downloadable executable
available on his website.  The primary need, beside the obvious need
that it in fact work, is that the executable be as tiny as possible to
encourage potential clients in turn to download and use it.

The second project is a set of modules for internal use by the company
I now work for.  The primary focus, again besides the obvious need for
it to be functional, is that it be highly maintainable and easily
modified by the senior most programmer or the newest, week-old junior
developer.  Anybody must be able to look at the code, understand it
quickly and easily, and be able to modify parts as required.

If I employed the same style of programming in both of these projects I
would be a fool.  Some of the styles implemented to make a small
executable in any other circumstance would be considered incredibly bad
practice, yet there it is, working perfectly and being incredibly small
while doing so.  Meanwhile some of the code within the second example is
incredibly verbose and a seasoned coder would look at it and say "Why
for the love of python are you doing this the long way round?" ... once
again, it fulfills it's specification perfectly while doing it's job to
the satisfaction of all concerned.

When it comes to implementations of twisted, one must take into
account the context in which the program is being developed and the
specific use cases it requires.  No two implementations will ever be
the same, and no two implementations should ever use twisted in exactly
the same way.  To expect identical or even similar usage of a module in
every single instance is poor practice in itself.

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".

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.

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.

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.

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.

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).

--
Clive Crous
http://www.darkarts.co.za/