On 5 Nov, 09:19 pm, [EMAIL PROTECTED] wrote:
On Wed, Nov 05, 2008 at 07:24:31PM -0000, [EMAIL PROTECTED] wrote:
On the other hand, the approach you're describing here, using Twisted
"just a little", ... is basically an architectural antipattern,
which should be avoided as much as possible.
I agree that it should be avoided as much as possible, but I don't
think
that it should be impossible to do. Suppose, for example, that you are
refactoring a project to use Twisted.
Sure.
Give me any API, and I can create a program that misuses it. :)
Oh, come on. This is a totally bogus argument, and I suspect you
already know that :). First of all, it's not true: in some languages (E
comes to mind) it is possible to create APIs which are literally not
abusable (for some suitable definition of "abuse", this one about global
state included).
It's the thing Perl people say when you corner them and make a strong
case that Python is objectively more readable than Perl. "Sure, but you
can create an unreadable program in any language". That's not the
point; the point is, does tool X make it more *likely* that you'll
create maintainable programs? Does X help people learn how to create
maintainable programs? Twisted should be doing those things.
I think the following use cases for mutliple reactors outweigh the
potential risks:
This is almost certainly true, and as I've already said I am keenly
interested in de-globalizing the reactor myself; making it easier to
test things is a key reason for doing so. However, we should be aware
of the risks and try to mitigate them. It could well be that we could
come up with an API which is smooth as glass for the "good" use-cases we
have in mind here, and raises exceptions or emits helpful warnings when
used for the "bad" ones. Maybe that's not possible, maybe we can only
get halfway there: but it would be nice to try.
In fact, it would be a much better influence on architecture to have
intentional, helpful error messages rather than buggy, non-deterministic
and unsupported behavior.
- k threads that each have their own reactor
This is a whole other, almost unrelated can of worms. You can only use
Twisted from one thread at a time. There are things which make
assumptions about non-reentrancy and mutual exclusion of global module-
level state. You can find and fix every instance of this if you want,
but don't bundle it in with multiple reactors :).
It's nice to be able to say "you can't do that, it's impossible", when
someone asks how to set up something like that.
If I wanted to be constantly told "you can't do that, it's impossible",
I wouldn't be a Python guy. If I want to shoot myself in the foot,
that's my problem. :)
Another bogus argument. There are lots of things that are "impossible"
in Python. For example, you "can't" change the values of a tuple, or
the contents of a string. I mean, there's terrible stuff you can do
with ctypes, but if it breaks, you get to keep both pieces. Similarly,
there are lots of things that already kind of work, by accident, if you
instantiate multiple reactors; you can kind of re-set a reactor if you
know exactly what to twiddle.
When I say it's nice to be able to say that something's impossible, that
doesn't mean that I don't want to support all the reasonable use-cases,
just that boundaries are a useful tool. This is very much the Python
idiom - consider your options for indenting your code in strange ways,
for example :).
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
