Mailman 3 August 2017 - Twisted

[Twisted-Python] HTTP/2 and getPeerCertificate
by Lance Kurisaki Aug. 27, 2017

Aug. 27, 2017

With HTTP/1.1, I used to be able to call request.transport.getPeerCertificate(). When the client uses HTTP/2, however, it seems that request.transport is None. How does one access the transport with HTTP/2? Thank you... Lance

2 1

[Twisted-Python] Chunked decoding missing from HTTPClient?
by Barry Scott Aug. 21, 2017

Aug. 21, 2017

I see that HTTPChannel knows about chunking and indeed works well. However shouldn't HTTPClient also support chunking? Or Am I missing something to get chunking working for the response from a server? Barry

2 4

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Aug. 20, 2017

Aug. 20, 2017

1 0

[Twisted-Python] Nevow 0.14.3rc1 released
by Tristan Seligmann Aug. 19, 2017

Aug. 19, 2017

Hi all, I've uploaded a prerelease of Nevow 0.14.3 to PyPI[1]. This contains a fix for some Athena client-side timeout behaviour (or more specifically, the lack of one) and removes use of FilePath.getmtime. If you are using Athena, please a) let me know! and b) give this prerelease a try to see if anything breaks. As the de facto Nevow release manager, and one of its last users, I'd like to avoid going overboard on release engineering if it isn't necessary, but I'd also like to avoid making life worse for any other remaining users, so it would be useful to hear from any of you out there still using Nevow. [1] https://pypi.python.org/pypi/Nevow/0.14.3rc1

2 3

[Twisted-Python] trial.unitest-specific segfault with lxml
by Phil Mayers Aug. 18, 2017

Aug. 18, 2017

This is an odd one; I have a simple test using the incremental xmlfile() feature of lxml, that crashes *only* if the test case inherits from trial.unittest.TestCase; it works if inheriting from unittest.TestCase. SSCCE - well, hopefully correct - here: https://gist.github.com/philmayers/387597c7407ab98f159426cea5f44a69 With lxml 3.8.0 (tried both manylinux1 wheel from PyPI and locally-compiled) and a debug python, I get: $ bin/python2-debug -m twisted.trial test_repro.py test_repro Test test_one ... [OK] test_two ... [OK] ------------------------------------------------------------------------------- Ran 2 tests in 0.032s PASSED (successes=2) python2-debug: /builddir/build/BUILD/Python-2.7.13/Python/getargs.c:229: vgetargs1: Assertion `compat || (args != (PyObject*)NULL)' failed. Aborted (core dumped) Obviously lxml is a pretty big chunk of Cython, but the trial-specific nature of the crash has me curious which of the two is at fault. I have tried to debug it, and it basically seems to end up somewhere inside the Cython-generated code with an argument to a python function that is NULL when it shouldn't be. Any ideas?

2 2

[Twisted-Python] Is there a nice way to write transport-agnostic protocols and servers/clients?
by Jarosław Fedewicz Aug. 17, 2017

Aug. 17, 2017

Recently, I needed to write a client for a server which can listen on one of these: 1) TCP 2) UDP 3) Unix stream sockets 4) Unix datagram sockets And pain it was, as a matter of fact. The only thing that was easy was the streaming protocols part. In the datagram land, it was all different: 1) I had to cope with a fact that transport.connect() only really works with UDP, and employ a workaround which allowed me to use the same protocol class for both UDP and Unix datagrams 2) setting up client for UDP and datagram is a wildly different procedure: for Unix datagram sockets, I use reactor.connectUNIXDatagram(), for UDP I need to use reactor.listenUDP(0, ...) which is fairly confusing to say the least 3) endpoints, for some reason, with connection parameters as strings, and unified connection routine do not exist for datagram protocols at all 4) it seems either impossible or really hard to create a transport-agnostic protocol (with the bulk of logic defined on an upper layer, and framing/messaging defined at the transport level protocol classes), which could be connected to any endpoint it supports, using clientFromString() or serverToString(). The number of protocols that use TCP or UDP interchangeably is quite high. Some applications where Twisted would be an appropriate choice, could even work with non-TCP/UDP transports, like QUIC, DCCP, STCP, etc. (I haven't even looked at the issue of lower layers or other address families yet, there be dragons.) My question is: does anyone share my pain? Is there some kind of ongoing effort to design an API or anything else? What can I do to help? -- Yaroslav Fedevych IT Philosopher

6 14

[Twisted-Python] 17.5.0 _newtls.pu:207 loseConnection signature problem
by Barry Scott Aug. 14, 2017

Aug. 14, 2017

I porting some code to latest twisted and I;m seeing the old code expects to call loseConenction with a reason. But loseConnection in class ConnectionMixin does not have the parameter. Is this an oversight or deliberate? Barry

2 2

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Aug. 13, 2017

Aug. 13, 2017

2 1

[Twisted-Python] need a name for an endpoint forwarder (twist/twistd plugin)
by Brian Warner Aug. 10, 2017

Aug. 10, 2017

Hey, so I had a need the other day for something like Twisted's built-in "twist portforward" module (which takes a TCP port to listen on, and when someone connects, it proxies that connection to a TCP port on some other host). Except I wanted something more general: portfoward can listen on any endpoint, but it can only connect to TCP targets (it takes a host+port, rather than a generic endpoint description, and there's a hard-coded reactor.connectTCP inside). You can add new types of endpoints by installing packages that include plugins that implement IStreamClientEndpointStringParserWithReactor. For example, a plugin that knew how to speak SRV (which is TCP except you have to do a DNS lookup for the port number first) would enable an endpoint like "srv:example.org:smtp". With a generic portforwarder, this would let you leave a twist/twistd process running, and then point your (non-SRV-aware) applications at a local TCP port, but they'd really connect to the right SRV-mediated target service. Which might be a lot easier than rewriting the application, or finding some shared-library tricks that let you modify the way it does the connect() call. It was pretty easy to write, and the code is in https://github.com/warner/tx-endpointforward . But before I publish it, I wanted to see if anyone had a better idea for a name. Or whether something like this exists already and I just didn't find it. I've seen projects with names like "tx-foo" and "txfoo" and "txFOO", and I wasn't sure what the current consensus is. Also, the twist/twistd plugin name could be better, running "twistd endpointforward" is kind of verbose. "epfwd"? "epforward"? Or, should this just be a patch to the built-in portforward.py module? Maybe enhance it to take either a single endpoint argument, or a pair of HOST,PORT args (which it turns into an endpoint descriptor with "tcp:%s:%d"). Any thoughts? -Brian

2 1

[Twisted-Python] ANN: Crochet 1.8.0, now with unmangled function signatures
by Itamar Turner-Trauring Aug. 9, 2017

Aug. 9, 2017

Crochet lets you use Twisted in any blocking Python program: Django, Flask, wherever you want. Another use case: if your Twisted program uses threads, it also has some utilities that make it easier to call back into Twisted from threads. Crochet 1.8.0 makes decorated function signatures match the original signatures, for better IDE and doc-generation support. It also has fix for AWS Lambda, and improved documentation. https://github.com/itamarst/crochet for source, docs at https://crochet.readthedocs.io/en/stable/, pip install crochet to get it. -- Itamar Turner-Trauring

1 0