Mailman 3 April 2004 - Twisted

[Twisted-Python] http://www.smartpeer.com -- another twisted success story
by Anthony Baxter 21 Apr '04

21 Apr '04

So Michael Marmor has released a Morphix derivative (a bootable CD version of Linux) that just includes PythonDirector, making the machine a TCP loadbalancer in a box. PythonDirector is of course based on Twisted. I think this is pretty cool, and could be good for the twisted success stories page. See http://www.smartpeer.com/ for the software. (ObDisclaimer: while I wrote PythonDirector, I've not had anything to do with SmartPeer other than offering advice and encouraging words) Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Re: [Twisted-Python] twisted and interactive/command driven input
by exarkun＠divmod.com 21 Apr '04

21 Apr '04

On Thu, 15 Apr 2004 12:58:41 -0000, "Ellers" <ellers(a)ellerton.net> wrote: > > [snip] > > I've got a basic interactive shell going on its own no probs, > and as mentioned I've got a separate basic twisted client going > too. > > Can anyone point me at examples or tips on how to use twisted > for handling the socket comms and still allow interactivity > with the user? > An example of handling stdin input asynchronously is available here: http://svn.twistedmatrix.com/cvs/trunk/doc/examples/stdin.py?view=markup&re… It does not demonstrate how to combine handling stdin input and dealing with sockets, but since nothing special is required for that combination, it should get you going in the right direction. Jp

1 0

[Fwd: Re: [Twisted-Python] Sub-project Naming]
by Christopher Armstrong 21 Apr '04

21 Apr '04

So it's officially counted :-) :: -------- Original Message -------- Subject: Re: [Twisted-Python] Sub-project Naming Date: Tue, 20 Apr 2004 12:47:45 -0700 (PDT) From: Jeremy Noetzelman <jjn(a)kriln.com> To: Christopher Armstrong <radix(a)twistedmatrix.com> FWIW, tmlabs.* has my vote! Stravad -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/

15 20

Re: [Fwd: Re: [Twisted-Python] Sub-project Naming]
by exarkun＠divmod.com 21 Apr '04

21 Apr '04

On Tue, 20 Apr 2004 17:23:56 -0400, Bob Ippolito <bob(a)redivi.com> wrote: > > [snip] > > > So because there are good reasons either way, I say we just stick with > the cute names -- but maybe try a little harder to market them to new > users. An idea would be to have a "protocol matrix" document that is > easy to find from twistedmatrix.com (no more than 1 click away from the > front page, but it could almost be the front page) that is a table of > wire protocols <-> implementation names with perhaps a note about their > stability and completeness. > As a first pass: |Wire Protocol |Impl mod(s) |Framework mod(s) Completeness (IMHO, 1..10) dict t/p/dict.py -- 2 dns t/p/dns.py t/names/ 4 (pending rewrite) finger t/p/finger.py -- 8 ftp t/p/ftp.py -- 5 http t/p/http.py t/web/ 7 (pending rewrite) ident t/p/ident.py -- 10 imap4 t/p/imap4.py -- 8 irc t/p/irc.py t/im/, t/words/ 6 jabber t/p/jabber/ -- not a clue msn t/p/msn.py -- not a clue nntp t/p/nntp.py t/news/ 4 (pending rewrite) oscar t/p/oscar.py -- not a clue pop3 t/p/pop3.py t/mail/ 8 (pending Q changes) sip t/p/sip.py -- not a clue smtp t/p/smtp.py t/mail/ 9 socks v4 t/p/socks.py -- not a clue xml t/p/sux.py -- not a clue telnet t/p/telnet.py -- 4 toc t/p/toc.py t/im/ not a clue echo, discard, chargen, qotd, who, daytime, time t/p/wire.py -- 9 Perspective Broker t/spread/banana.py, t/spread/jelly.py, t/spread/pb.py t/spread/ 8 (pending rewrite) ssh t/conch/ssh/ t/conch/ 9 Btw, looking at the first two columns of this table, I think that Twisted does a kick-ass job of naming most of its modules in an understandable and approachable manner :) Jp

1 0

[Twisted-Python] Library Versioning
by James Y Knight 21 Apr '04

21 Apr '04

Yeah, everyone's probably going to get mad at me for bringing versioning up again, but here goes. I'll structure the first bit as an argument between me and some argumentative type who is unconvinced. ========= Me: I want to be able to have two apps installed that use different, incompatible revisions of twisted or twisted subprojects. Other: You can just install multiple versions of Twisted, in different directories, and set your PYTHONPATH differently for the different apps. And this works *right now*. Me: Yes, that is true. But I want a solution to work for e.g. distributed debian packages. If twisted core makes an incompatible API change and becomes major revision 2, I want to be able to install applications that depend on v1 and applications that depend on v2 at the same time. I want to be able to apt-get install AppA which uses on libtwisted-core-1, and AppB which uses libtwisted-core-2 and have them both work. Other: Okay, so call the newer API twisted_2 and the old one twisted_1 (or just twisted). What's the problem? Me: A few problems. First problem is you have to litter the entire codebase of an application with the version numbers. Every time you import the module you have to add the revision. When you want update your app to use 2.0, you need to change every single file to use twisted_2, even if they otherwise needed no changes. What I really want to do is put the required version in *ONE* place in the app. Perhaps in its __init__.py, or (if it's an app), perhaps in its executable script file. Other: No, you *DON'T* want that, you really do want to specify the version in every import because you want to be able to import both versions in one "app". Me: But it is unlikely that two revisions that don't know about eachother will both work in one app, so while it may look like I can import twisted_1 and twisted_2, mixing them will likely cause my app to blow up. Other: Right, which is why the new version supplies the old interface as well. So the Twisted 2.0 library can provide both twisted_2 *AND* twisted_1 reimplemented in terms of twisted_2. And then you *can* use both in one app and everything will be happy. Me: Yes, that is possible. If you do that, you're not breaking API compatibility, and thus the new version isn't actually a major revision at all. I do concede, it is _always_ better to not break API compatibility if you can avoid it. But I only know of one major opensource library that is making a guarantee to never release a new major version: glibc. Most projects do not have unlimited programmer time, and keeping backwards compatibility forever can take a lot of time and testing. Also note the "again" there. Me: I think that having every API version supported by one library version is a very different thing than just being able to install multiple distinct versions of the library. Even if the goal is to support every API revision for eternity, it's probably not always possible, and at that point, you would want multiple library versions installed simultaneously. ========= Thus, I propose the following magic (I'll have you take for granted that might work, for the moment): This explicitly *DOES NOT* attempt to solve the multiple APIs supported by one installed library version issue. That is a separate issue. - "import twisted; twisted.setversion(xxx)" loads version xxx of the twisted library. If another version has already been loaded, or if the specified version isn't available, raise an exception. - "import twisted" uses the already loaded version if one is loaded, or else looks for the latest installed version and loads that if none have been loaded. After that, you can use twisted.whatever normally. The setversion only needs to be done once per app/library e.g. in the top level __init__.py. It can be done in more places if you want. This has the following desirable characteristics to me: 1) Simple case for beginners -- they don't have to do anything about versioning at all. Just import twisted normally and they get the latest version they have installed (which may very well also be the only version they have installed). 2) Yet, still easy to add the version requirement to an app that didn't have it initially. That you make sure to call setversion only really matters for packaged or widely distributed apps/libs. So if you're package an app that didn't have a setversion call initially, add it -- a one line patch. 3) Allows distro packaging to work sensibly. Incompatible revisions can be installed side-by-side and apps that use the old one can continue working just fine. 4) Doesn't require possibly unfulfillable compatibility promises from developers going forward. This kind of versioning is somewhat similar to that of Python itself: - You have a python app, and you can specify the version required on the first line of the main program (#!/usr/bin/python2.3), or else not (#!/usr/bin/python). - Multiple versions are simultaneously installable. - New versions have some compatibility, but don't promise perfect compatibility. Thus, sometimes you don't need to do anything to make your app work with the new version. But, if you do, there's likely only a few things you need to change, not every file. - If the new version of python implements a compatibility API this is a separate issue from the python version: to get the old API you do nothing, and to get the new API you do: from __future__ import whatever. James PS: (The magic above does seem to be implementable, see PMW, Python Mega Widgets.)

1 0

[Twisted-Python] connection to AIM often unsuccessful using twisted's example AIM bot
by Tim 21 Apr '04

21 Apr '04

I am running the very simple example aimbot given by twisted. The code can be found at http://twistedmatrix.com/documents/current/examples/aimbot.py Sometimes when I run the script it connects successfully. The majority of the time, however, it times out and I get this: C:\progra~1\Python23\lib\site-packages\twisted\internet\base.py:516: Deprecation Warning: connectionFailed is deprecated. See new Client API self.protocol.connectionFailed() I usually get this message every time I try to connect, except for brief periods of time (usually 10 minutes at most) during which I can connect reliably. Anyone know what's going on? Any way I can fix this problem? Thank you!

1 0

Re: [Twisted-Python] Progress report on splitting packages
by exarkun＠divmod.com 21 Apr '04

21 Apr '04

On Tue, 20 Apr 2004 11:53:29 -0400, Itamar Shtull-Trauring <itamar(a)itamarst.org> wrote: >Three suggestions so far: > > 1. Separate namespaces for each project. > > twisted.internet > conch Advantages: Easy on developers No distutils tricks required Disadvantages: Litters the top-level namespace Less uniquely named packages must be renamed > > 2. Keep all projects and core under twisted. > > twisted.internet > twisted.conch > Advantages: Easy on users. Keeps the top-level namespace clean. Keeps Twisted projects conceptually tied together. Disadvantages: Distutils tricks required Missing projects confuse users ("importing twisted.conch failed? But I have Twisted installed :(") > 3. Separate namespace for projects, e.g. 't' or 'tmlabs' (Zope3 was > considering using 'z', though it like it won't happen in the end - > http://mail.zope.org/pipermail/zope3-dev/2004-April/010469.html) > > twisted.internet > t.conch or tmlabs.conch > Advantages: Keeps the top-level namespace clean. Keeps Twisted projects conceptually tied together. Disadvantages: May require distutils tricks. Missing projects confuse users, but probably less than in #2 Amendments to the above advantage/disadvantage lists welcome. I mentioned "distutils tricks" a couple times. So far I have heard both that distutils can and cannot do this. I suspect that it can, but I would like to hear details on how this would work. In particular, I would like to know whether "twisted.foo" would exist before the "foo" project was installed, and if it would, both what it would consist of and how it would be treated when twisted core is being upgraded after the "foo" project has been installed (can it cleanly avoid overwriting things?). I am not sure which of these I support yet, but I think I am leaning towards #3. Jp

5 5

[Twisted-Python] Sub-project Naming
by Ed Suominen 21 Apr '04

21 Apr '04

"Always, always, always use good, unabbreviated, correctly-spelled meaningful names." - http://c2.com/cgi/wiki?MeaningfulNames As I've posted on the twisted.web list and ranted on #twisted, I feel very strongly that the proposed subprojects for twisted should have meaningful names that convey their function and relationship with each other. On the #twisted IRC channel, Itamar talked about the use of tmlabs as a prefix for the subproject names. This makes perfect sense to me. What would you rather see in a list of packages, this: TimmysToy Lowdown Dot or this: tmlabs.web tmlabs.news tmlabs.dns Which is easier for the uninitiated user or potential user of twisted to comprehend? Do you want to convey information in a name or hide it? -- Ed Suominen Registered Patent Agent Open Source Developer (Yes, both...) Web Site: http://www.eepatents.com

4 3

[Twisted-Python] Free Microsoft VC++ Compiler
by Justin Johnson 21 Apr '04

21 Apr '04

Did anyone see this? http://msdn.microsoft.com/visualc/vctoolkit2003/ Not sure if this is anything we'd want to use, but thought I'd through it out here.

5 6

RE: [Twisted-Python] Progress report on splitting packages
by Schneider, Michael 21 Apr '04

21 Apr '04

Just curious. Is there a technical reason not to do three layers. It seems Application - twisted Domain - news Subsystem - lowdown , .... makes the system easier to understand then Application - twisted All subpackages - next level.... Just trying to understand the approach, Thanks Mike ---------------------------------------------------------------- Michael Schneider Senior Software Engineering Consultant UGS PLM Solutions - an EDS Company "The Greatest Performance Improvement Is the transitioning from a non-working state to the working state" > -----Original Message----- > From: twisted-python-bounces(a)twistedmatrix.com > [mailto:twisted-python-bounces@twistedmatrix.com]On Behalf Of Itamar > Shtull-Trauring > Sent: Tuesday, April 20, 2004 9:48 AM > To: Twisted discussion stuff > Subject: Re: [Twisted-Python] Progress report on splitting packages > > > On Tue, 2004-04-20 at 09:34, Thomas Mangin wrote: > > > twisted.mail.pop3.byme > > twisted.mail.pop3.byyou > > twisted.nntp.lowdown > > twisted.nntp.cnn > > Not going to happen. twisted.news... maybe. twisted.news.lowdown or > whatever is not going to be how we do it. > > -- > Itamar Shtull-Trauring http://itamarst.org > Looking for a job -- http://itamarst.org/resume.html > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python(a)twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python >

1 0

Twisted April 2004