Mailman 3 August 2013 - Twisted

[Twisted-Python] Buildbot downtime
by Tom Prince 03 Mar '22

03 Mar '22

I am plannig to upgrade twisted's buildbot in the near future. In preperation for that, I am going to take down the production buildbot on Tuesday, June 26, around 1600 UTC[1]. During that time, the result of any builds done will be lost. Thus, I'd ask that people avoid committing to trunk during that time. I will send a reminder before I take down the buildbot both here, and on #twisted and #twisted-dev. Tom [1] http://timeanddate.com/worldclock/meetingtime.html?iso=20120626&p1=80&p2=22…

2 8

[Twisted-Python] Twisted Python 0.7.0 Prerelease Testing
by Glyph Lefkowitz 05 Aug '21

05 Aug '21

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. Thanks. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/

4 5

[Twisted-Python] Real Viagra Professional - for real sex pros
by Tamika 01 May '19

01 May '19

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <center> <a href="http://rqf.entercompassion.com"><img src="http://mediapix.ru/pics/685207b3dd437eff7f15c0744b5c1d3a.gif"> <title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="stylesheet" href="http://gfx8.nnt.com/mail/12.0.1187.0824/positioning.css" /> </head> <body style="overflow:auto;"> <div id="PrintShellToolbar"> <div class="ContainerPadding"> <span class="FloatRight"> <a href= > <img alt="" src="http://gfx1.nfi.com/mail/w2/pr02/ltr/glyph_close_rest.gif" /> <Close window> <a href= > <img alt="" src="http://gfx2.czb.com/mail/w2/pr02/ltr/i_print.gif" /> <Print> </a> </span> </div> </div> <div> <div class="BorderContainerOutline ContainerPadding"> <div class="ClearBoth"> <span class="HeaderData" style="font-size:large;"> <TuPostal.com Cambia de nombre?> </span> </div> <div class="ClearBoth"> <span class="HeaderLabel"> <From:> </span> <span class="HeaderData"> <b><TuPostal.com></b> </span> </div> <div class="ClearBoth"> <span class="HeaderLabel"> <Sent:> </span> <span class="HeaderData"> <div class="ClearBoth"> <span class="HeaderLabel"> To: </span> <span class="HeaderData"> Mikelelliott (mikelelliott(a)rlo.com) </span> </div> <br /> </div> </div> <div class="MessageBody" style=""> <br /> <div id="MessageBodyText" class="ExternalClass" style="border: 1px solid #fff ;"> <pre>Hola!<br> <br>Tupostal es ahora parte de Sonico!<br> <br>Para conocer nuestro nuevo sitio, haz clic en el siguiente link:<br><a href='http://www.gwpcom/index1.php' target='_blank'>http://www.bjncom/index1.php</a><br> <br>Sonico es un sitio donde puedes...<br>- Guardar fotos ilimitadas<br>- Re encontrarte con viejos amigos<br>- Recibir novedades de tus amigos.<br> <br>Te Esperamos! Ya somos mas de 21 millones de usuarios!!<br> <br>Sonico - Amigos Conectados<br> <br> <br>PD: Ahora tambien podras guardar tus postales<br> <br> <br>------------------------------------------<br>Haz recibido este email porque te encuentras registrado en fdm.com.<br>Si no deseas recibir mas mensajes como este, por favor haz clic en el siguiente link:<br><a href='http://www.cehcom/unsubscribe.php?type=2' target='_blank'>http://www.fyocom/unsubscribe.php?type=2</a><br> <br></pre> </div> </div> </div> </body> </html>

8 10

[Twisted-Python] [ANN] txZMQ released
by Andrey Smirnov 21 Jul '14

21 Jul '14

Hi! I would like to announce txZMQ, ZeroMQ bindings for Twisted. txZMQ is based on pyzmq and requires recent ØMQ version (>=2.1). txZMQ uses ØMQ APIs to get file descriptor that is used to signal pending actions from ØMQ library IO thread running in separate thread. txZMQ should be usable with any Twisted reactor. ØMQ is: * The socket library that acts as a concurrency framework. * Carries messages across inproc, IPC, TCP, and multicast. * Connect N-to-N via fanout, pubsub, pipeline, request-reply. * Fast enough for clustered products and supercomputing. * Asynch I/O for scalable multicore message-passing apps. Bridging ØMQ and Twisted makes a nice match: fast simple messaging between Twisted instances solving complex problems :) Links: * PyPi: http://pypi.python.org/pypi/txZMQ/ * Source code: https://github.com/smira/pyzmq * pyzmq: http://pypi.python.org/pypi/pyzmq * ØMQ: http://www.zeromq.org/ -- Andrey Smirnov, Qik Web Team Lead

8 11

[Twisted-Python] regarding xml elements
by Raj kumar 02 Oct '13

02 Oct '13

Hi, I have an xml file in my application, I have created an element using Example goes like this......... document.createElement("abc") and i appeneded it by using append() method. But how i can reflect this change to my xml file? and one more thing is i want to create element with some other parameters.... like............. <abc m=" " n=" "> </abc> and i have m and n values as strings with me. can anybody help me to create this element and write it to the existing xml file as a child of an existing element? Thanks in advance.. Raj.. Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php

9 14

[Twisted-Python] logging
by Glyph 18 Sep '13

18 Sep '13

Hello everybody. Today I'd like to talk about everyone's favorite subsystem within Twisted: logging. There are a number of problems with Twisted's logging system. The general theme of these problems is that Twisted log system was designed with some intended use-cases in mind, but its implementation was stopped halfway through and none of those use-cases were really well satisfied. At various conferences, and in person at various times, we've gotten together to express frustration at the logging system, but I don't think that the problems with it have ever been really thoroughly written down. Wilfredo has been working on logging here: http://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/lo…. This began as an attempt to just address some issues with our own logging wrappers, but has been growing into a design that is more fully capable of replacing logging within Twisted wholesale. I hope one of us can contribute it to Twisted soon, but in the meanwhile, please feel free to provide feedback - hopefully if some people can provide a bit of informal feedback now, the formal review process can be shorter and more pleasant :). Now, back to some explanation of the current problems. The main intended use-case for Twisted's logging system is to avoid doing unnecessary work in the case where it is not required. One of the reasons we even still have our own logging system is that the stdlib logging module is notorious for doing too much work per log message, and doing it too prematurely. One aspect of this is that logging would just use the existing 'kwargs' dictionary as its message type, and not actually do any formatting; that is, string-copying, until the message was logged. On Python 1.5.2, that meant no need to allocate anything since the interpreter needed a dict for the kwargs anyway! Woohoo premature optimization! Obviously, at least on PyPy, that optimization is no longer relevant (and we don't have performance tests for logging anyway). But, I don't think we should change that because a dict is still a good object for the sort of extensibility that log messages need. But, we have never written any filtering logic, nor have we instrumented any of our existing log messages with formatting stuff. Every message with a format string just goes to the log. For a long time, there's been consensus among at least a few core Twisted developers that log messages ought to be specified in terms of a format message and several relevant keyword arguments, so that tools can extract the values of the keyword arguments without parsing ad-hoc messages or using regexes. In other words, like this: log.msg(format="Foo happened. Relevant information includes: " "bar=%(bar)s baz=%(baz)s boz=%(boz)s", bar=bar, baz=baz, boz=boz) Yet, nothing within Twisted itself does this. There's a bit of a chicken and egg problem: since we have no tools for filtering log messages based on their structured values, there's no obvious motivation to break the structured contents of a message out into those values. And since no messages break out their values into nice structured fields, there's no motivation to write filtering tools that inspect those fields. And, even if we did have filtering, we don't have a facility to easily defer work. You could, of course, just do something like this: class GenerateOnlyIfNeeded(object): def __str__(self): return doSomethingExpensiveToGenerateAString() log.msg(format="debugging: %(expensive)s", logLevel=debug, expensive=GenerateOnlyIfNeeded()) But that's an awful lot of thinking for a single log message, not to mention the temporary class and the method you needed to allocate. Such deferral of work should be easy. And, speaking of the things that one might filter on, log messages don't typically include information about what module and class they're from; or, for that matter, what object is logging them. This information should be included by default in idiomatic usage of the API, so that a filtering system can inspect them. Another reason that we - both Twisted itself and Twisted users - don't typically pass keyword arguments and a format string, is that the default argument to msg is, simply, a "message". (It also does a dumb thing where it tries to emulate the argument-passing convention of 'print' and stringify its arguments and join them with spaces; we should get rid of that.) Instead, that argument always ought to be a format string. We should also have a log writer within Twisted that preserves structure, and dumps the logs using JSON (or similar, perhaps more than one of these; AMP would be another good thing). It's also not possible to use format strings when you are writing an error log message in Twisted; instead, 'why' is treated completely differently than 'message'. The 'why' argument to 'err', which should be mandatory (what were you doing when you tried to log a message?) is optional, which means that error messages are even more inscrutable. The portions of the dictionary used by the logging system are not namespaced in any way, even by convention. Therefore it's easy for a user to conflict with the keys used by the system. If users of Twisted actually used the system as intended more pervasively, I'm pretty sure that we would end up seeing people conflict with 'time' and 'system' arguments often. Speaking of those keys: the 'time' key is unconditionally overwritten by log.msg, which means that re-publishing an event that happened previously is destructive; there's no way to track historical time. Messages logged before the logging system starts are just lost. It would be good for the initial log observer to keep a (limited-size, of course) buffer of log messages which could be dumped upon failing. This would make it easier, for example, to debug tap plugins that use the log system to report something about their state during makeService. (And, as the maintainer of a phenomenally complex makeService, I can tell you that this would definitely be helpful.) The naming of methods is bad and confusing. msg? err? Easy to type, but hard to understand. We could have equally short names that are not confusing. The contract between parts of the system is poorly specified. For example, trial -j has a hard time with log output that includes any non-bytes keys. I imagine this will only become worse when trial actually supports Python 3. And speaking of encoding, the log system is written in terms of bytes instead of in terms of unicode. Now, there's good reason to be particularly permissive of garbage data in the logging system (logging a message should never provoke an error), but at some point - probably before the data gets to user-written observers - everything should be normalized into a structure that has enough properties that the user can depend on it. On that note, when presented with unicode encoding errors, Twisted's logger will directly raise an exception back to application code, something that it will otherwise only do when presented with KeyboardInterrupt. That I just don't understand. We use old, semi-deprecated '%' formatting style. If we're going to introduce a new API, we should use PEP 3101 formatting; in addition to being new and improved instead of old and inferior, it's a lot easier to type {foo} correctly than to type %(foo)s without forgetting the s. The whole LogContext thing is poorly designed. Mea culpa; this was entirely my fault. One problem with its design was that it was somewhat poorly explained, and so its intent has not carried over years of maintenance. The idea was supposed to be that every event-source within Twisted would provide a useful system key, which would indicate what event-source object (TCP connection, listening port, timed event, UDP port) was being activated when the given message was logged. However, a lot of factors conspire to make this information less than useful. For one thing, especially in database-backed applications, or those that are careful about rate-limiting or flow-control, nothing ever happens except in response to a callFromThread or a callLater; this means that the system argument is always "-". I think that the feature this is trying to support needs to be fundamentally re-thought (and in the intervening decade I've had a lot of ideas about how it might work better). Maybe we can build on some of Chris Armstrong's recent work on Deferred debugging in tracking asynchronous context in Deferreds to help identify the real cause(s) of work being executed. OK, I think that's it for now. (NB: The implementation linked above doesn't address all of the issues I've enumerated in this message, and I don't think that it should address every single one of them before being added to Twisted; writing this one message took me long enough, but we should possibly also discuss which ones are fundamental issues with the logging system and which are features that should be considered separately.) -glyph

12 40

[Twisted-Python] Python 3: bytes vs. str in twisted.python.filepath
by Harry Bock 15 Sep '13

15 Sep '13

Hi all, My name is Harry Bock. I'm interested in helping out porting Twisted to Python 3, and I've popped in IRC a few times to introduce myself and ask a few questions. A few developers agreed that working on trial dependencies would be a big help. In doing some porting work on trial, I stumbled upon a previous porting effort (possibly by Itamar?) for twisted.python.filepath and related modules. It seemed like the porting effort included forcing all pathname inputs to be byte strings instead of native strings. After some investigation, I believe this is the wrong approach, but I wanted to start a discussion here first. Some thoughts: (a) As of Python 3.3, use of the ANSI API in Windows is deprecated[1], so many functions in os and os.path raise DeprecationWarning when given byte strings as input. Although win32 is not an initial target of the porting effort, we'll have to support it eventually and the API should be supported before then. (b) Misunderstandings at the application level about the underlying filesystem's path encoding is not the problem of the Twisted API. Correct me if I'm wrong, but that's the responsibility of the system administrator or individual user (at least on UNIX) to set the LANG environment variable, or for the application to call setlocale(3) to explicitly override it. (c) If we do not allow unicode strings, we will be forcing the application developer to decide how to encode paths when using the FilePath API. Per (b) above, the user will have to call sys.getfilesystemencoding()[2] to divine what encoding to use before using the API at all, which to me is terribly annoying and would just add str.encode calls everywhere. Thus, my vote is that on Python 2.x, Twisted should accept either the native str or unicode types for path names, and on Python 3.x, only accept the str type to prevent deprecation issues with system calls. I have a patch set that will make this happen including unittest modifications; if there's a consensus I'm happy to open a ticket and submit the patches. Thanks! [1] http://bugs.python.org/issue13374 [2] http://docs.python.org/3/library/sys.html#sys.getfilesystemencoding

5 7

Re: [Twisted-Python] Advice on porting Python application to Twisted
by Tom Sheffler 01 Sep '13

01 Sep '13

Hi Matthew - I have a couple of idioms I use for #2 and #3 in your message. Here they are. #2) For timer events, I create a function that when called, continuously schedules itself again in the reactor, does some work for the current tick, and then exits. I've used this down to 1-second intervals. If you're looking for sub-millisecond level timing, this may not be appropriate for your application. def timerFunction(reactor): reactor.callLater(1.0, timerFunction, reactor) # do the work for this time tick # etc etc return # Somewhere in main do this to kick it off from twisted.internet import reactor timerFunction(reactor) #3) For subprocesses, I like to create a custom protocol for each type of sub-command I am calling. I also like to create an object to manage the process, its arguments, its results and its temp files. The idiom below is suitable for calling a subprocess that accepts a small amount of buffered data on stdin, produces some output on stdout, and logs its stderr. Be careful examining the value of reason.value.exitCode in processExited. The twisted docs show printing the exitCode as a "%d", but sometimes the value is None --- if the process was terminated by a signal. The mere printing of the value with "%d" will then trigger an exception! Here's my idiom: class FooprocProtocol(protocol.ProcessProtocol): def __init__(self, foomgr): # the object managing my subprocess self.foomgr = foomgr # my stdout data self.data = "" def connectionMade(self): # Pump input data in using this, and then close stdin log.msg("connectionMade!") # self.transport.write("...") # if there is any data to shove into stdin self.transport.closeStdin() def outReceived(self, data): # collect up our stdout log.msg("outReceived! with %d bytes!" % len(data)) self.data = self.data + data def errReceived(self, data): # echo stderr messages to log with a marker log.msg(">%s" % data) def inConnectionLost(self): print "inConnectionLost! stdin is closed! (we probably did it)" def outConnectionLost(self): log.msg("outConnectionLost! The child closed their stdout!") def errConnectionLost(self): log.msg("errConnectionLost! The child closed their stderr.") def processExited(self, reason): log.msg("processExited:%s:" % reason) exitcode = reason.value.exitCode # an integer or None # do some work upon processExit potentially make a decision on exitcode ... log.msg("processExited:%s" % exitcode) def processEnded(self, reason): print "processEnded, status %s" % (reason.value.exitCode,) # process the data in the process manager exitcode = reason.value.exitCode # might be non-numeric result = self.foomgr.processData(exitcode) # The main job of the Process Manager is to build the command list and # process the results. It gives us a handy place to encapsulate this # logic. class FooprocManager(object): CMD = "/usr/local/foocmd" def __init__(self, arg1, arg2, arg3) # create a Deferred to fire when we succeed or fail self.d = Deferred() # build our command argument list as appropriate for our command self.cmdargs = self.build_cmd_args(arg1, arg2, arg3) # define places to store the transport, pid and other things self.ptransport = None self.pid = None def build_cmd_args(self, arg1, arg2, arg3): # in my projects, this method has become fairly involved as it creates # tmp files and builds potentially complicated argument lists. arglist = [self.CMD, arg1, arg2, arg3] return arglist def run(self): # instantiate a protocol connected to this manager pp = FooprocProtocol(self) # spawn the process, save the PID self.ptransport = reactor.spawnProcess(pp, self.CMD, self.cmdargs, { }) self.pid = self.ptransport.pid def processData(exitcode): # in my projects, this method opens up result files, parses results, # moves things around, deletes tmp files, etc. # return the result that we ran this subprocess for return result # Instantiate a new process manager and run it this way. mgr = FooprocManager(args ...) d = mgr.run(args ...) ================= T

3 5

[Twisted-Python] Raising exception from a Deferred canceller.
by zhang kai 30 Aug '13

30 Aug '13

Hi, As itamar mentioned in ticket #6676 <http://tm.tl/#6676>, If a cancellation function for a Deferred throws an exception(the cancel() method of Deferred won’t throw exceptions, but the canceller may), behavior is undefined. If the cancellation function throws an exception it is currently not caught, and cancellation does not occur. We can catch the exception and log it, and fallback to just firing Deferred withCancelledError. This won’t break any old code. But an exception raising from the cancellation function often means the cancellation is failed. Another option we have is taking this opportunity to make the cancellation being able to fail. There is the motivation: There are cases where a Deferred is uncancellable. For example, we can call twisted.mail.imap4.IMAP4Client.delete to delete a mailbox. When the operation is waiting in the queue, we can cancel it by removing it from the queue. However, when the operation is already sent and is waiting for the response, it becomes uncancellable. If we allow the canceller(NOT the cancel() method of the Deferred) to raise an exception, we can tell the user the cancellation is failed and the Deferredwon’t be fired with a CancelledError. Raising an exception from cancel() may break the old code. So we can catch the exception raised by the canceller, then return a False without firing theDeferred to tell the user that the cancellation is failed. In order to avoid missing unexpected exceptions, we can create a CancellationFailedError. When the canceller raises CancellationFailedError, we catch it and return False. When the canceller raises others exceptions, we catch it, log it then return False. Something like this: def cancel(self): if not self.called: canceller = self._canceller if canceller: try: canceller(self) except CancellationFailedError: return False except Exception: log.err(None, "Unexpected exception from canceller.") return False else: # Arrange to eat the callback that will eventually be fired # since there was no real canceller. self._suppressAlreadyCalled = True if not self.called: # There was no canceller, or the canceller didn't call # callback or errback. self.errback(failure.Failure(CancelledError())) return True elif isinstance(self.result, Deferred): # Waiting for another deferred -- cancel it instead. return self.result.cancel() else: return False This won’t break any code by raising an exception from cancel(), although some code may rely on cancel() not returning any value. So, what’s your opinion on raising an exception from the canceller? Regards, -Kai

4 6

[Twisted-Python] Twisted serialport dataReceived() provides fragmented data
by Sivakumar Balasubramanian 29 Aug '13

29 Aug '13

I am tyring to implement a python program, using Twisted, to communicate witha bluetooth device. The following is a sample code of what I have implemented: from twisted.internet import protocol, reactor from twisted.internet.serialport import SerialPort from twisted.protocols import basic class DeviceBluetooth(basic.Int16StringReceiver): def connectionMade(self): print 'Connection made!' self.sendString('[01] help\n') def dataReceived(self, data): print"Response: {0}".format(data) print "-----" print "choose message to send: " print "1. Stim on" print "2. Stim off" print "3. Stim status" print "4. Help" # user input ch = input("Choose command :: ") if int(ch) == 1: self.sendString('[02] stim on\n') elif int(ch) == 2: self.sendString('[03] stim off\n') elif int(ch) == 3: self.sendString('[04] stim ?\n') elif int(ch) == 4: self.sendString('[05] help\n') else: reactor.stop() SerialPort(DeviceBluetooth(), 'COM20', reactor, baudrate=115200) reactor.run() When I run the program, sometimes I get a response and other times I do not receive anything. And most of the times long responses are fragmented appear as part of the next message. I have through the hyperterminal to make sure that I get the appropriate response from by bluetooth device. So, the problem has to be with my code. Is there something that I doing wrong in my code?

2 3