[Twisted-Python] removing unsupported reactors in twisted 2.6:

[glyph at divmod.com]

On Sun, 24 Sep 2006 10:54:15 -0400, Itamar Shtull-Trauring <itamar at itamarst.org> wrote:

>Removing is a bad idea, although adding quality warning seems like a
>good idea:

Where would you suggest adding that warning?

>qt is failing *7* tests out of 3034, all but one i; that doesn't seem to
>merit removing it. If there were serious problems I would expect we
>would have many bug reports from qt users, but we don't.

I don't expect that we'll ever hear from users about anything, unless we threaten them directly :).

Qt is definitely in a better situation than the other reactors we're talking about.  However, it's very likely that code could be added or changed which would make it "redder" and nobody would notice until well after the fact.  Can we set those tests to 'skip' or 'todo' in the context of the Qt reactor and call that "good enough"?

tsreactor failed something like 30 tests the first time I ran trial on it and something like 100 the second time.  The third run did not complete.  I assume it's mainly race conditions which are killing it, but I don't know where they are.

>tsreactor is private in twisted - starts with _, so it doesn't really
>guarantee anything or make any promises about working, and it's very
>useful for integrating with broken event loops.

It's exposed to users as a reactor on the command line.  Maybe *that* should have an "_" added to it as well.  However, if we're going to keep it around, it should have a buildbot, end of story.

>wxreactor is a tsreactor wrapper which makes it suck less for the wx
>case. AFAICT wx is one of the most popular ui toolkits for python, so
>people will want to use it;

If it's so popular, why does nobody care enough to contribute a few patches to make it work properly?

>wxreactor for all it faults is in most cases going to be way better than whatever people try to do on their own,

I agree, but mainly because the average case of "whatever people try to do on their own" is going to be ad-hoc and untested.  Right now the alternative we are proposing is also ad-hoc and untested, just in a smaller way.

>especially if the branch I have lying around is ever merged.

What branch is that?  Should it be marked for review?

At any rate, it sounds like YOU care enough about wxreactor to put some effor into it, which is enough to satisfy me.  Should we add a --reactor option for wx, and set up a buildbot for wxreactor?

>The basic argument here is the same:

>1. People want to use these GUI toolkits.
>2. They will thus either drop Twisted and write their own networking
>framework, or they will write their own GUI integration code. Both of
>these cases result in code that is likely will be worse than our current
>providing.

This is true for the moment, but eventually some of the code in quesiton is going to decay to the point where it is so seriously out of sync with the rest of Twisted that it won't even import.

>So as long we are up front and visible about existing limitations in
>these reactors, our users benefit by us including them.

I don't think we have nearly enough visibility on the quality or stability of those reactors.  "Stability: Unstable" means "we might change this", not "it is known to be broken and to fail numerous tests".