------------------ Virus Warning Message -------
Found virus WORM_SOBIG.F.DAM in file document_all.pif
The uncleanable file document_all.pif is moved to /var/iscan/virus/virzvbjnq.
This is the Postfix program at host kappa.utc.fr.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<Sebastien.Barre(a)utc.fr>: unknown user: "sebastien.barre"
Our virus detector has just been triggered by a message you sent:-
Subject: Your details
Date: Fri Aug 22 14:50:53 2003
One or more of the attachments (application.pif) are on
the list of unacceptable attachments for this site and will not have
Consider renaming the files or putting them into a "zip" file to avoid
The virus detector said this about the message:
Report: Shortcuts to MS-Dos programs are very dangerous in email (application.pif)
No programs allowed (application.pif)
On Thu, 2003-08-14 at 20:49, Christian Reis wrote:
> Actually, you're correct. Guido replied to python-dev today (but
> unfortunately omitted you from the CC: list) the following:
> From: Guido van Rossum <guido(a)python.org>
> Date: Thu, 14 Aug 2003 07:54:19 -0700
> Cc: python-dev(a)python.org
> X-Spambayes-Classification: ham; 0.00
> > > Which form do I need to fill out? "Proposed Contributor
> > > Agreement" seems a bit much. I don't need a cvs account. Maybe
> > > "Proposed Contibution Licensing Agreement"?
> > Well, the situation is a bit confused at the moment. To my
> > knowledge *noone* has signed one of these agreements yet -- I
> > certainly haven't.
> That's because we're still discussing them with lawyers (a year too
> long :-( ).
> Eventually we'll want one from you too. In this specific case of
> code that is known to be distributed as part of glibc as well, I
> think it's important to have an explicit paper trail from the
> original author (who better be the author of *all* lines he's
> contributing to us :-).
> I recommend that he sign the Proposed Contribution Licensing
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> So, being Guido the BDFL, I'd take his word on it. I think the process
> would be filling out the form, mailing it and dropping a note to
> python-dev(a)python.org (or replying to the original mail) letting people
> know that the form has been sent. I'll try and take care of the rest
> from there (and I'll let you know if something has come up).
I mailed this today.
Alexander Larsson Red Hat, Inc
He's a Nobel prize-winning amnesiac firefighter with a mysterious suitcase
handcuffed to his arm. She's a virginal out-of-work politician looking for
love in all the wrong places. They fight crime!
I would like to get some feedback on some thoughts that I've been
having about cooperative multitasking using generators. After some
attempts to change that 'flow' module  into a C module, I got thinking
about how to better support my requirements with a relatively small
change to the Python interpreter.
Anyway, if you would humor me a bit, perhaps you can see what I'm
getting at; perhaps the change to Python could be relatively localized
and simple. And Python would be quite more useful in cooperative
First, let me provide an application context.
Suppose you are building a webpage in response to an HTTP request.
Further suppose that the information for this web page comes from
two sources, a PostgreSQL database and an OpenLDAP directory. Now
assume that you want to make your page building modular, that is,
broken into several operations with sub operations. Here is,
perhaps a call graph of how the page would be done:
| | writeTopOfHeader
| | writeMetaKeywords
| | queryLDAP* (returns iteratable keyword sequence)
| | writeRestOfHeader
| | writeTopOfNavigator
| | writeNavigatorRows
| | queryLDAP* (to get items for the Navigator)
| | writeRestOfNavigator
| | writeTopOfGrid
| | writeRows
| | queryDatabase* (returns sequence of rows )
Assume that each of these items is a generator, and that queryLDAP,
and queryDatabase generators either yield a value (in the sequence
that they return) or return a special sentinel 'Cooperate'. Then,
assume that you have a reactor which is building N pages at a time.
To make this magic work, each one of the intermediate generators
(buildPage, buildGrid, writeRows) on the way to a leaf generator
(queryDatabase) must explicitly check for this 'Cooperate' special
value, and then yield themselves with this same value. In this
way, you can 'pause' the whole chain of generators. The flow
module  tries to make this easy, and makes the logic for
'Cooperate' to work by scheduling each page to be build.
Second, let me describe the problem (or irritant)
Well, what happens in the flow module, is that each one of the
intermediate generators needs to be 'wrapped' to handle exceptions
and other concerns. This wrapper slows things down substantially,
especially in tight loops. Furthermore, each intermediate generator
must be made 'aware' that it may be paused (an unnecessary ickyness)
for example, the following code:
for x in parentGenerator:
# do something with X
has to be rewritten as:
parentGenerator = flow.wrap(parentGenerator)
for x in parentGenerator:
# do something with X
It works, but it is just stuff that I think could be done much
better in the guts of python itself. And without all of the
tricks needed to coax exceptions into working as you'd expect.
Third, let me describe what I 'think' would be a nice solution
I'd like a special value, lets call it Pause, which can be given
to a yield statement. When this is encountered by the Python
interpreter, it bypasses all of the intermediate generators
and goes to the most recent non-generator. For example, in the
a queryDatabase yield of Pause would bypass the chain
(buildPage, buildGrid, writeRows) and the caller of buildPage's
next() method would receive the Pause object. Then, when the
next call to buildPage's next() method is invoked, it would resume
the top level generator (queryDatabase) and if that generator
yields a non-Pause value, the stack would unwind as normal.
So, in an attempt to be more explicit:
- Let a generator chain C be composed of three generators, g, g', g''
which are calling each other. Let f be a function which is
iterating over the generator g.
- Let the generator g'' yield a value p, which is a subclass of a
special 'Pause' built-in class.
- At this point, the Python evaluator goes down the stack frame to
find the first non-generator in the stack, in this case, f.
- And then the evaluator creates a new instance zzz of a PauseIter
object. Then, every instance of g in f is replaced with zzz.
At this point, zzz is initialized with g and g'', as the head and
tail of the paused generator.
- The function f is given the value p as its result of g.next()
- When the function f calls g.next() again (which actually calls
zzz.next() instead), the generator g'' is resumed.
- If g'' yield another Pause object, then this object is passed
back to the function f, and things continue
- If g'' yield a non-Pause object, then f() is rewritten to
link to g again, and the non-Pause object is handed to g'
so that normal processing proceeds
- If g'' creates an exception, then f() is rewritten to
link to g again, and the exception object is percolated
down to g' for normal processing.
Fourth, in conclusion
I think with a chance similar to above, Cooperative Multitasking
in Python with the ability to break-down generators into
sub-generators becomes easy to manage (a function f can simply
keep each micro-thread in a queue, etc.).
I'm not sure if I understand the implications of all of this,
and in particular, how hard a ceval.c would be, but I'd be
very interested to hear your opinion.
>>> Absender <<<
Diese Nachricht wurde automatisch generiert von:
Mail Scanner, Universitaet Osnabrueck, Rechenzentrum
>>> Informationen <<<
Der Mail Scanner hat eine infizierte Mail entdeckt,
die Ihre Absender-Adresse traegt. Diese Mail ist
*nicht* an die Empfaenger weitergeleitet worden.
>>> Virus-Beschreibung (englisch) <<<
Subject: Re: Approved
Scanning part 
Scanning part [thank_you.pif]
Attachment validity check: passed.
Virus identity found: W32/Sobig-F
>>> Massnahmen <<<
Moeglicherweise ist Ihre Absender-Adresse ohne Ihr
Wissen verwendet worden.
Sollte sich Ihr Rechner als viren-frei herausstellen,
betrachten Sie diese Mail nur als Benachrichtigung,
dass Viren unter missbraeuchlicher Verwendung Ihrer
Absender-Adresse verschickt worden sind.
In diesem Fall sind keine weiteren Massnahmen notwendig.
Andernfalls pruefen Sie bitte den Datei-Anhang (Attachment) auf
den gemeldeten Virus ("Virus identity found"), bevor Sie
die Mail erneut versenden. Hinweise zur Desinfektion finden
Sie auf der Heimatseite von Sophos unter http://www.sophos.com.
Mit freundlichen Gruessen
Mail Scanner, Universitaet Osnabrueck, Rechenzentrum
I just received a message from you. Unfortunately it contained
an attachment that is not permitted to be sent to this server.
The message was DELETED!
Please zip the attachment and resend the message with the zipped
If you did not send a message, it was probably a virus that reported
you as the sender.
There is no need to reply to this message.
Kaspersky Anti-Virus 4.0.0 reports a problem: you sent a message with a virus !
In the following message:
Please check your computer with Kaspersky Antivirus Scanner!
Your mail to 'viewcvs' with the subject
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
The original message was received at Wed, 20 Aug 2003 02:31:34 -0400 (EDT)
from pcp01709343pcs.south01.md.comcast.net [184.108.40.206]
----- The following addresses had transient non-fatal errors -----
----- Transcript of session follows -----
... while talking to gro.dd.org.:
>>> RCPT To:<cc(a)dd.org>
<<< 450 <cc(a)dd.org>: User unknown in local recipient table
<cc(a)dd.org>... Deferred: 450 <cc(a)dd.org>: User unknown in local recipient table
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old