ANN: Twisted 1.1.1
Itamar Shtull-Trauring
applications.
For more information, visit http://www.twistedmatrix.com, join the list
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python or
visit us on #twisted at irc.freenode.net.
The Twisted from Scratch tutorial is a good starting point for learning
Twisted: http://twistedmatrix.com/documents/howto/tutorial
What's New in 1.1.1
===================
- Many bug fixes and minor improvements.
- MSN protocol support updated to support MSN8P.
- Conch SSH client now supports SSH auth agent.
What is Twisted?
================
Twisted is an event-driven framework for building networked clients and
servers. It contains a powerful and simple networking core, a
full-featured suite of interoperable protocols, among them a powerful
web server and applications framework.
Jarek Zgoda
> Twisted is an event-driven networking framework for server and client
> applications.
>
> For more information, visit http://www.twistedmatrix.com, join the list
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python or
> visit us on #twisted at irc.freenode.net.
>
> The Twisted from Scratch tutorial is a good starting point for learning
> Twisted: http://twistedmatrix.com/documents/howto/tutorial
I am really angry that I cann't write Twisted-based applications on daily
basis since I think it's really coolest network framework I could ever
dream of!
Writing one more asyncore/asynchat application pisses me off. Hate it.
Love it. Thanks God, it's Python, not Rexx, even not Java.
NP: The Cure - The Loudest Song
--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zg...@chrome.pl http://zgoda.jogger.pl/
Cameron Laird
Jarek Zgoda <jzg...@gazeta.usun.pl> wrote:
.
[thoroughly deserved
praise for Twisted]
.
.
>Writing one more asyncore/asynchat application pisses me off. Hate it.
>Love it. Thanks God, it's Python, not Rexx, even not Java.
.
.
Think about that last just a bit more. Asyncore is SUCH an
upgrade over what most of the world is doing.
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Jarek Zgoda
>>Writing one more asyncore/asynchat application pisses me off. Hate it.
>>Love it. Thanks God, it's Python, not Rexx, even not Java.
> .
> Think about that last just a bit more. Asyncore is SUCH an
> upgrade over what most of the world is doing.
Yes, you are right, most of world still uses synchronous sockets.
AFAIK, asynchronous sockets are widely used in ObjectPascal (by way of
F. Piette's work), but I don't know any such complete (like these in
Python and ObjectPascal) implementation in other Popular Programming
Environments (Java is PPE, Rexx is my *local* PPE ;))
Lawrence Oluyede
> .
> Think about that last just a bit more. Asyncore is SUCH an
> upgrade over what most of the world is doing.
Can you explain "over what most of the world is doing" a bit more?
I'm seriuosly interested.
--
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
Irmen de Jong
> cla...@lairds.com (Cameron Laird) writes:
>
>
>> .
>>Think about that last just a bit more. Asyncore is SUCH an
>>upgrade over what most of the world is doing.
>
>
> Can you explain "over what most of the world is doing" a bit more?
> I'm seriuosly interested.
[Perhaps a bit offtopic?:]
While you're at it-- is there somewhere a *recent* tutorial on
using asyncore/asynchat? Sam Rushing's one (found via Google)
is from 1999...
(I'm interested in using asyncore directly, not as part
of a framework such as Twisted or Medusa).
--Irmen.
Jarek Zgoda
>>>Think about that last just a bit more. Asyncore is SUCH an
>>>upgrade over what most of the world is doing.
>>
>> Can you explain "over what most of the world is doing" a bit more?
>> I'm seriuosly interested.
>
> [Perhaps a bit offtopic?:]
>
> While you're at it-- is there somewhere a *recent* tutorial on
> using asyncore/asynchat? Sam Rushing's one (found via Google)
> is from 1999...
> (I'm interested in using asyncore directly, not as part
> of a framework such as Twisted or Medusa).
Frederik Lundh has excellent chapter on network protocols with many
examples for asynchronous servers and clients in his "Python Standard
Library" book, available online at
http://effbot.org/zone/librarybook-index.htm
It's the best I have found.
Jarek Zgoda
>> Think about that last just a bit more. Asyncore is SUCH an
>> upgrade over what most of the world is doing.
>
> Can you explain "over what most of the world is doing" a bit more?
Most of the world still blocks execution with synchronous sockets. Event
driven programming is not a wholly accepted idea.
Irmen de Jong
> Frederik Lundh has excellent chapter on network protocols with many
> examples for asynchronous servers and clients in his "Python Standard
> Library" book, available online at
> http://effbot.org/zone/librarybook-index.htm
Thanks for the link, I'll go and read it!
And kudos to Fredrik for putting this stuff online.
--Irmen.
Cameron Laird
Jarek Zgoda <jzg...@gazeta.usun.pl> wrote:
>Lawrence Oluyede <ra...@dot.com> pisze:
>
>>> Think about that last just a bit more. Asyncore is SUCH an
>>> upgrade over what most of the world is doing.
>>
>> Can you explain "over what most of the world is doing" a bit more?
>
>Most of the world still blocks execution with synchronous sockets. Event
>driven programming is not a wholly accepted idea.
.
.
Sooooooo true. Hang out with Perlites or C++ians sometime;
you'll hear them talk about how easy it is to do networking
now, and then they start saying words like "fork" and "thread".
My point is that their accepted concurrency models involve
serious burdens in regard to performance and developmental
fragility.
Mr. Zgoda's right: event-driven networking remains poorly
appreciated, and those of us who favor it find it MUCH
preferable to the alternatives.
Just
cla...@lairds.com (Cameron Laird) wrote:
> In article <br849l$qp9$8...@atlantis.news.tpi.pl>,
> Jarek Zgoda <jzg...@gazeta.usun.pl> wrote:
[ ... ]
> >Most of the world still blocks execution with synchronous sockets. Event
> >driven programming is not a wholly accepted idea.
> .
> .
> .
> Sooooooo true. Hang out with Perlites or C++ians sometime;
> you'll hear them talk about how easy it is to do networking
> now, and then they start saying words like "fork" and "thread".
> My point is that their accepted concurrency models involve
> serious burdens in regard to performance and developmental
> fragility.
>
> Mr. Zgoda's right: event-driven networking remains poorly
> appreciated, and those of us who favor it find it MUCH
> preferable to the alternatives.
This ties nicely into the xsdb + stackless discussion:
- threads + blocking sockets is attractive since the code can be
written in a natural style, yet cause overhead and
synchronization headaches.
- async sockets are attractive because they avoid threads and
therefore avoid overhead and synchronization issues. Yet it
is often a bit harder to code, since you need to turn your
code inside out, using callbacks.
But there is a "perfect" solution: co-routines. With co-routines you can
both write the code in a "natural" style, but still using an even-driven
core. This is a very pleasant model to work with, so I totally
understand that some people (eg. Aaron) choose to use Stackless to make
this possible.
Just
Andrew Bennetts
>
> This ties nicely into the xsdb + stackless discussion:
>
> - threads + blocking sockets is attractive since the code can be
> written in a natural style, yet cause overhead and
> synchronization headaches.
>
> - async sockets are attractive because they avoid threads and
> therefore avoid overhead and synchronization issues. Yet it
> is often a bit harder to code, since you need to turn your
> code inside out, using callbacks.
>
> But there is a "perfect" solution: co-routines. With co-routines you can
> both write the code in a "natural" style, but still using an even-driven
> core. This is a very pleasant model to work with, so I totally
> understand that some people (eg. Aaron) choose to use Stackless to make
> this possible.
co-routines miss one of the features of the threading model, though, which
is preemptive concurrency. I prefer the async way of working too, but I can
see that co-routines don't provide the best of both worlds...
-Andrew.
Richie Hindle
[Jarek]
> Most of the world still blocks execution with synchronous sockets. Event
> driven programming is not a wholly accepted idea.
I just came across this in Moshe Zadka's blog. Not strictly relevant but
it made me smile:
"The correct way to explain [async programming] is as some kind of Zen,
and even Buddhism.
In order to program on the network, which is filled by buggy and evil
agents, one must give up all expectations. One must sit quietly, without
desires to plague the flesh, quietly meditating. Only when an event is
received, one must react to it, and then get back to meditating. In this
way, enlightment is achieved. This is why async systems have no read()
call. Reading from the network means you have expectations of what will
arrive. If it doesn't, your hopes are shattered. If you have no hopes to
shatter, you cannot be disappointed."
(Whether, like a lot of Eastern philosophy, the truth of that can only be
appreciated by people who have *already* achieved async enlightenment, I
don't know. 8-)
--
Richie Hindle
ric...@entrian.com
Just
Andrew Bennetts <andrew-p...@puzzling.org> wrote:
True, that is an important difference. However, I believe that people
often pick threads over events not because they need preemptive
concurrency, but because threading appears to be "easier" -- which it
is, at least if you discount synchronization issues. Co-routines largely
fix that particular problem.
Just
John J. Lee
> [Jarek]
> > Most of the world still blocks execution with synchronous sockets. Event
> > driven programming is not a wholly accepted idea.
>
> I just came across this in Moshe Zadka's blog. Not strictly relevant but
> it made me smile:
>
> "The correct way to explain [async programming] is as some kind of Zen,
> and even Buddhism.
>
> In order to program on the network, which is filled by buggy and evil
> agents, one must give up all expectations. One must sit quietly, without
> desires to plague the flesh, quietly meditating. Only when an event is
> received, one must react to it, and then get back to meditating. In this
> way, enlightment is achieved. This is why async systems have no read()
> call. Reading from the network means you have expectations of what will
> arrive. If it doesn't, your hopes are shattered. If you have no hopes to
> shatter, you cannot be disappointed."
:-)
Now, if he'll just publish that in a glossy magazine and make
asynchronous network programming fashionable... then half of all
programmers will mindlessly stop using threads even when *they're* the
sane way to do the job :-(
John
If you ever reach total enlightenment while you're drinking a beer, I bet
it makes beer shoot out your nose.
Jack Handey
Ville Vainio
> Now, if he'll just publish that in a glossy magazine and make
> asynchronous network programming fashionable... then half of all
FWIW, in Symbian pretty much every program is single threaded, w/
comms and such handled by asynchronous "Active Objects" and "Active
Scheduler" that execs the RunL method of Active Object when the object
has stuff to do.
This is mostly done to save resources, allegedly.
--
Ville Vainio http://www.students.tut.fi/~vainio24
A.M. Kuchling
Irmen de Jong <irmen@-NOSPAM-REMOVETHIS-xs4all.nl> wrote:
> While you're at it-- is there somewhere a *recent* tutorial on
> using asyncore/asynchat? Sam Rushing's one (found via Google)
> is from 1999...
Not really; I've been thinking of writing one, though, given that there are
still people using asyncore and the existing material is so sparse.
--amk