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 have an xml file in my application,
I have created an element using
Example goes like this.........
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....
<abc m=" " n=" ">
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..
Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php
On 18 May 2004, the following message was posted to this mailinglist:
Jp Calderone exarkun at divmod.com wrote:
>Daniel Newton wrote:
> I have a simple XML-PRC server similar to the example below:
> from twisted.web import xmlrpc, server
> class Example(xmlrpc.XMLRPC):
> """An example object to be published."""
> def xmlrpc_add(self, a, b):
> """Return sum of arguments."""
> return a + b
> if __name__ == '__main__':
> from twisted.internet import reactor
> r = Example()
> reactor.listenTCP(7080, server.Site(r))
> I want to be able to get the address of the client that calls the
> method can anyone help me with this?
This solution didn't work because 'transport' isn't a property of the
I'm currently in the process of changing from a customized
SimpleXMLRPCServer to a twisted XMLRPC server solution and I need to
insert the client IP into the attributes passed to the called xmlrpc
method. Anyone who knows the answer and is willing to share the info?
I have the beginnings of some task-based documentation available in
twisted-docs (https://github.com/tdavis/twisted-docs) now. You can find the
built version in the usual place (http://docs.recursivedream.com/twisted/)
-- just remember to bust the cache.
I chose serving web content as a starting point because it seems as common a
task as any. I took some examples from the existing howto (
as well as added some examples of further learning and glossary entries to
make the point. Obviously there's nothing completely usable here yet; it's
primarily an exercise in showing how I'd like to split up sprawling,
semi-random docs like *using-twistedweb* into more coherent, digestible,
stackable pieces. A document to talk about core concepts (Site Objects,
Resources, etc.), sections for supplementary features like Sessions, Virtual
Another advantage of this style is that we can effortlessly stitch together
our own tutorials (were that ever a goal) just by linking in step-wise
fashion to ever-advanced tutorials which themselves wrap back around to core
concepts like, in this case, Applications and the IService stack. It should
be up to the user how deep into the rabbit hole they want to go; right now I
have to slog through two sections to get to a part that tells me how to just
serve a directory of HTML.
In our project, we accumulate data from various sources. Some of them are
connected via serial line (e.g. a GPS receiver and a weather station).
I'd like to run the application with twistd. But it looks as if SerialPort
does not really fit into this framework. It does not implement IService,
so `my_serial_port.setServiceParent(collection)` does not work.
Is there any technical reason that SerialPort does not implement
IService? Could you suggest a workaround for this problem (other than
dumping t.a.s.Application ;-))?
Weiermayer Solutions GmbH | Abteistraße 12, A-4813 Altmünster
phone: +43 (0) 720 70 30 14 | fax: +43 (0) 7612 20 3 56
In this thread, I hope to find a resolution to the issue of the Finger
tutorial and efforts to sufficiently improve it or remove it.
In the course of reviewing documentation-related tickets, I stumbled upon
#1148 (http://twistedmatrix.com/trac/ticket/1148). Therein, Glyph first(?)
put down a lot of things we've been discussing and agreeing upon in the
Refactoring Documentation thread. One of the issues still up for debate is
whether or not the Finger tutorial is sufficiently strong to survive the
documentation overhaul. There are various points against it right now:
- It isn't tested or even test*able*
- It doesn't cover "best practices" as they relate to writing testable,
maintainable code, etc.
- It attempts to implement basically every main Twisted concept, often in
contrived or poorly-executed ways
- It has been said it has, "...at best, the potential for mediocrity."
There are also enough tickets related to refactoring / rewriting it that a
resolution would make a significant dent in the list of stale documentation
tickets. Among these two year-old tickets are:
- http://twistedmatrix.com/trac/ticket/532 - Big jump from finger18.py to
finger19.py in tutorial
- http://twistedmatrix.com/trac/ticket/626 - Split tutorial finger code
- http://twistedmatrix.com/trac/ticket/2205 - Documentation codelistings
need updating and tests
This shouldn't be a blocker on anything Kevin and I are doing, but it'd be
nice to concurrently have discussions on issues we'll need to address later.
I'm also pretty anal about ticket lists and if these aren't going anywhere
I'd love to close them ;)
First off there isn't actually a twist, it's just for Twisted
addressing the points in #4671 . Sorry to disappoint. Secondly I
realise there are already at least a thousand Python enum libraries,
most of which I haven't explored, feel free to mention these with
My point of view is that a great many number of these enum libraries
go to long lengths to make stuff too "cute". While having less
not-networking-related code in Twisted may be a more desirable route,
Twisted makes enough use of enum-esque things in the current code base
that it may be easier (maybe even warranted) to have our own
implementation that can cater directly to the needs of Twisted without
being subjected to the usual irritations of third-party software; also
Twisted's high-qualilty coding and testing standards are only a good
The current code is hosted on Launchpad  and the source code is
viewable on the web . I am aware that there are currently no
unittests or any kind of useful documentation, hopefully the examples
are good enough for now. I'm hoping for some feedback to decide
whether to press ahead or turn back. I've tried to look at as many
Twisted enum use-cases as possible, without trying to cater to every
one individually, however I do still have a few questions:
1. #4671 uses an "asInt" method in the examples, this is obviously
going to require changing all code that uses these enums (of which
there is plenty.) Is this a good idea? It seems easy to forget that
"F_FOO | F_BAR" is not giving you a number.
2. I use "__int__", I don't know if this is horrible or not and
whether I should just use the "asInt" method proposed in the ticket.
3. It seems to me that there are two general cases:
1. The enum just holds values that have an interesting meaning on
their own (e.g. AMP special keys (ASK, ANSWER, etc.), IRC status codes
(RPL_WHOIS, etc.)) and combining them makes no sense.
2. The enum holds values that are intended to be combined. i.e. flags.
Does it make sense to try and combine this behaviour into the same
type? Currently it is and you get an exception when doing certain
things (none of which make any sense, in this context):
>>> (Words.AYE | Words.BEE)
<EnumValueGroup '|': [<EnumValue Words.AYE: 'a'>, <EnumValue Words.BEE: 'b'>]>
>>> (Words.AYE | Words.BEE).value
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "enum.py", line 77, in value
return reduce(self.op, values)
TypeError: unsupported operand type(s) for |: 'str' and 'str'
<EnumValue Words.AYE: 'a'>
>>> Words.fromValue('c') # This value is not in the enumeration and ORing values to get it is impossible.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "enum.py", line 133, in fromValue
if target - v < 0:
TypeError: unsupported operand type(s) for -: 'str' and 'str'