Search bar offers the following options:
Term presence. The below example searches for documents that
must contain “foo”, might contain “bar” and must not contain “baz”:
+foo bar -baz
Wildcards. The below example searches for documents with words beginning with “foo”:
Search in specific fields. The following search matches all objects
in "twisted.mail" that matches “search”:
Possible fields: 'name', 'qname' (fully qualified name), 'docstring', and 'kind'. Last two fields are only applicable if "search in docstrings" is enabled.
Fuzzy matches. The following search matches all documents
that have a word within 1 edit distance of “foo”:
Results provided by Lunr.js
A win32event based implementation of the Twisted main loop.
This requires pywin32 (formerly win32all) or ActivePython to be installed.
To install the event loop (and you should do this before any connections, listeners or connectors are added):
from twisted.internet import win32eventreactor win32eventreactor.install()
- WaitForMultipleObjects and thus the event loop can only handle 64 objects.
- Process running has some problems (see
- Event loop handling of writes is *very* problematic (this is causing failed tests). Switch to doing it the correct way, whatever that means (see below).
- Replace icky socket loopback waker with event based waker (use dummyEvent object)
- Switch everyone to using Free Software so we don't have to deal with proprietary APIs.
- IIRC, sockets can only be registered once. So we switch to a structure like the poll() reactor, thus allowing us to deal with write events in a decent fashion. This should allow us to pass tests, but we're still limited to 64 events.
- Instead of doing a reactor, we make this an addon to the select reactor. The WFMO event loop runs in a separate thread. This means no need to maintain separate code for networking, 64 event limit doesn't apply to sockets, we can run processes and other win32 stuff in default event loop. The only problem is that we're stuck with the icky socket based waker. Another benefit is that this could be extended to support >64 events in a simpler manner than the previous solution.
The 2nd solution is probably what will get implemented.
||Reactor that uses Win32 event APIs.|
||This mixin implements
||This wraps an event handler and translates notification in the helper