Mailman 3 April 2004 - Twisted

[Twisted-Python] http://www.smartpeer.com -- another twisted success story
by Anthony Baxter April 21, 2004

April 21, 2004

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 -- … [View More]

1 0

Re: [Twisted-Python] twisted and interactive/command driven input
by exarkun＠divmod.com April 20, 2004

April 20, 2004

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: … [View More]

1 0

[Fwd: Re: [Twisted-Python] Sub-project Naming]
by Christopher Armstrong April 20, 2004

April 20, 2004

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 April 20, 2004

April 20, 2004

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 > … [View More]

1 0

[Twisted-Python] Library Versioning
by James Y Knight April 20, 2004

April 20, 2004

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 … [View More]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.) [View Less]

1 0

[Twisted-Python] connection to AIM often unsuccessful using twisted's example AIM bot
by Tim April 20, 2004

April 20, 2004

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 … [View More]

1 0

Re: [Twisted-Python] Progress report on splitting packages
by exarkun＠divmod.com April 20, 2004

April 20, 2004

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 > … [View More]

5 5

[Twisted-Python] Sub-project Naming
by Ed Suominen April 20, 2004

April 20, 2004

"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 … [View More]

4 3

[Twisted-Python] Free Microsoft VC++ Compiler
by Justin Johnson April 20, 2004

April 20, 2004

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 April 20, 2004

April 20, 2004

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 … [View More]

1 0