hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
I'm working on a Flask project using the flask_twisted package from PyPI
and have encountered a mystery. I don't *have* to solve it to move on, but
darn it, I can't let it go :)
So here's the breakdown: when use the standard logging module to output to
a logfile + stdout, everything is fine. I do see some logging output from
Twisted as well (the web server part) but for the most part life is groovy.
I'm going to be integrating in a wxPython windows app to this (previously
it's been a shell app) and step 1 was to make my own stdout handler that
eventually would pipe all that stuff to a window in the wx app. The first
step of THAT (step 1.a) was to replace all the logging stuff with print()
At that point, things got confusing, as now ALL of my print()s are being
handled by Twisted's logging handler.
I brought flask-twisted in local to my code so I could monkey around with
it. First thing I noticed was that it was using twisted.python.log. I
messed around with that - commented it out, and now I get no stdout output
at all. Set the parameter setStdout to False, same thing.
The adapter code uses twisted.internet.reactor, threads,
twisted.web.server.Site, twisted.web.wsgi.WSGIResource, and
twisted.web.resource.Resource, any one which might be responsible. I spent
yesterday evening digging around but haven't found anything yet.
Any guidance / ideas?
I'm having an issue properly handling TLS failure modes. For example
consider the EchoServer and EchoClient code. If I use a TLS client with a
TCP4 server, I do not get a handshake exception until I abort the
connection. But I don't want to abort the connection unless I get a
What I'd like to do is to check the handshake status in my protocol before
my client sends bytes to the server. I'd like my send message to be able to
raise the <class 'OpenSSL.SSL.Error'>: [('SSL routines', 'ssl23_read', 'ssl
handshake failure'). But for some reason it seems to get lost until I abort
the connection. Does this sound familiar to anyone?
What I've done for now is setup a Timeout mixin so that after my
client.send, if I do not get an ACK back (which my particular protocol
does) within two minutes, I just abort the connection. This then calls
connectionLost with the correct SSL.Error. But if it's in the error queue
(and found during the course of abortConnection then isn't there a way to
find it sooner? Like before my timeout and before I call send on the client
I am working on ticket #9217 / PR #1051 to add lots more wheel
generation to the Twisted CI. I decided to give the cibuildwheel
package a try and it made this process almost too easy (well... sort of
:] ). I've got AppVeyor-Windows, Travis-Linux, and Circle-OSX all
building a variety of wheels for the supported Python versions and bit
depths. Travis doesn't save artifacts 'easily' so I went ahead and
doubled up on Linux on Circle for now, though it's having some Docker
issues at the moment and hasn't been successful yet. For some reason in
this one case the project directory isn't getting mounted into the
container as expected.
Now that I've got the wheel builds happening I figured it'd be good to
try them out on 'real' machines. Turns out we get a failure on
twisted.cred.test.test_strcred.SSHCheckerTests.test_isChecker for at
least the two checks I've done so far (Windows and OSX). I haven't done
more than a cursory look at that yet, but it's on the list to understand
and resolve. More testing would of course be welcome. Real world, just
trial Twisted's own tests, whatever would be appreciated if you are
failures with wheels:
Overall, it's a bit unclear what the intended use of the various CI
hosts are for Twisted. I hear that Travis OSX builds were really slow,
but from what I can see Circle isn't doing any OSX (other than what I
added). There wasn't any artifact storage being used on Circle either.
So, I'm not sure if there was a reason to use Circle that went away,
or... But, not having to hook Travis up to S3 or somesuch for storage
is quite nice so Circle wins at least in that category.
Now that I've got something rough in place, are there any opinions about
how this should work? I don't know the present release workflow so I
don't know if we'd want an automatic push to PyPI on tags (probably
not), or just artifacts on the build server to grab manually (would need
some S3 or such for Travis, or Circle for Linux builds as well).
Anything else? Do we want automated tests against the wheels?
cibuildwheel does have a feature for that though I haven't done anything
with it yet.
Anyways... hello, thanks for Twisted, and I hope this work ends up
saving some people some time.
I'm trying to use the -c option of twistd like this :
twistd web --wsgi bar.app -c foo.cer -k privkey.pem --https=4433
I'm pointing it at a cert with perms like this "-rw-r--r-- 1 root root" but twistd complains about a permission error .
I'm puzzled ... surely twistd only needs to read that file ?
After I start a reactor connecting to a specific hostname and port, I do my
thing and then call transport.write() to send the data to the peer.
>From what I can tell, though, the hostname is resolved, and the data is
written back to the ip address itself, instead of the hostname I started
the reactor with.
This is a problem in my case because we are using nginx's ssl_preread
server_name directive to route several different streams all coming in on
the same ip address.
So the write() method needs to explicitly use the hostname to route the
So... Is there any way to have transport.write() use the hostname given
instead of it's resolved IP address? Or am I missing something?
Crossposted on StackOverflow:
Thank you for any insight you may have!
Hi Twisted list!
I have a library that is attempting to start an AsyncioSelectorReactor,
fork the process, and then open a network socket on macOS. When the
network socket is opened, Twisted throws an [Errno 9] "Bad file
descriptor" exception at me. I get no such exception on Ubuntu.
If I change the sequence from:
fork_and_continue_in_child() # fork first
Then everything works okay.
Also if I use SelectReactor rather than AsyncioSelectorReactor then it
doesn't matter which order I fork in.
So my question is, does Twisted support being forked after starting a
reactor or not?
David Foster | Seattle, WA, USA
P.S. For more details see this Django Channels thread: