Mailman 3 October 2011 - Twisted

[Twisted-Python] Ticket #4519, other possible spawnProcess enhancments
by Andrew Mahone 10 Oct '11

10 Oct '11

I've been working on http://twistedmatrix.com/trac/ticket/4159 and there has been a bit of discussion on IRC regarding appropriate interfaces for various things. I think in the long run, the only python state that setupChild should be allowed to modify should be args, environment, and the win32 StartupInfo object. This leaves my own personal use case for it impossible, but I'm working out how to handle that - special childFDs objects. My proposal so far is that there be a ProcessFileDescriptor object that inherits from FileDescriptor. It would add a setup method, which Process would call in the parent, and separate finishChild and finishParent methods that would handle things like closing the other end of any pipe-like objects, and would return a file descriptor - the child would place this fd in childFDs, the parent would use it for communications with the child, in the case of objects that wrap pipes or PTYs. I would also extend the win32 implementation to include some limited support for childFDs - they could be used to allow the child to inherit specific file handles as its stdin, stdout, and stderr, instead of using these exclusively for communications with the parent, so that redirection to a pipe, to a file, and the building of pipelines could be accomplished on win32 (I have a project that uses twisted for this purpose, and I don't use windows, but I would like support to at least be possible). I'm seeking comments on whether an extended childFDs interface is the best way to manipulate the inherited files of the child process, and whether, if so, fdmap ought to be visible in setupChild at all - in my opinion, setupChild should be strictly for things like setting the child PID in an environment variable or as a command line argument, manipulating scheduler and other parameters external to twisted itself, and other things of that nature, and the existing childFDs mechanism should handle any manipulation of file redirection or inheritance. If there are suggestions on what an extended childFD object ought to look like, these are welcome as well - I think the specified methods should handle trivial cases even on platforms without fork, and should handle nearly anything that really is a file descriptor on POSIX platforms, but maybe there is something I have missed. -- Andrew Mahone andrew DOT mahone AT gmail DOT com

3 2

[Twisted-Python] Proposed new homepage
by Itamar Turner-Trauring 10 Oct '11

10 Oct '11

Our current page is not good at pulling in potential new users: * There's no quick examples of how nice Twisted is. * It takes 3 clicks (3!) to find basic documentation, with lots of scope for getting lost along the way. I propose to fix this by adding code examples, and relevant direct documentation links. A very preliminary pass, still lacking things like syntax highlighting, can be found here: http://twistedmatrix.com/trac/wiki/ProposedWikiStart What do you think?

6 12

[Twisted-Python] Weekly Bug Summary
by exarkun＠twistedmatrix.com 08 Oct '11

08 Oct '11

1 0

[Twisted-Python] Running the same trial test suite against a live server and a mock server
by Laurens Van Houtven 08 Oct '11

08 Oct '11

Hey, In order to properly test txievery (a twisted library for dealing with Paypal's APIs), I'm building a mock Paypal server. The idea is to run the same high-level tests (which basically use the API and eventually make it make real HTTPS requests) against both the mock server and the Paypal Sandbox. The problem is that using the Paypal Sandbox requires extra information: specifically, username, password, and an SSL certificate (I don't intend to support "signature" authentication. It's a horrible alternative for environments too stupid to make requests given a client cert). My mock sandbox also requires all of that, but I just have fake credentials. When you run the test suite against the Paypal Sandbox, obviously you're going to need Paypal-blessed credentials. The obvious solution is to have a makeClient function defined in module scope for the given test module. I could then have a bin/liveTest.py that takes a username, password and cert, and monkeypatches that module. I'm assuming it can't be hard to tell trial to just take a test module and run it... Are there any better ways to pass test data to trial? cheers lvh

4 3

[Twisted-Python] Sent e-mails coming up empty
by Laurens Van Houtven 05 Oct '11

05 Oct '11

Hey, I've hacked some code together based on smtpclient_tls.py and radix's article on how to send e-mail: http://radix.twistedmatrix.com/2010/07/how-to-send-good-unicode-email-with.… Here's what I've come up with: http://paste.pocoo.org/show/487918/ The e-mail arrives, but it's as if the body is empty. The from address is wrong (it uses my login email), there's no subject, no body... I've pointed my debugger at the problem, but the repr looks pretty okay: 'Content-Type: multipart/alternative;\n boundary="===============6076587290379738777=="\nMIME-Version: 1.0\nSubject: Content Access\nTo: _(a)lvh.cc\nFrom: dc83518c-4eea-447f-a9d8-29e29022e6f8(a)myotherdomain.com\n\n--===============6076587290379738777==\nMIME-Version: 1.0\nContent-Type: text/html; charset="utf-8"\nContent-Transfer-Encoding: quoted-printable\n\n<html>\n<body>\nOh hello!!!!!\n</body>\n</html>\n--===============6076587290379738777==\nMIME-Version: 1.0\nContent-Type: text/plain; charset="utf-8"\nContent-Transfer-Encoding: quoted-printable\n\n\nOh hello!!!!!\n\n--===============6076587290379738777==--' How do I go about debugging this further? cheers lvh

2 2

[Twisted-Python] Weekly Bug Summary
by exarkun＠twistedmatrix.com 01 Oct '11

01 Oct '11

1 0