Mailman 3 August 2003 - Python-Dev

Undelivered Mail Returned to Sender
by MAILER-DAEMON＠utc.fr Aug. 22, 2003

Aug. 22, 2003

------------------ 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"

1 0

Warning: E-mail viruses detected
by MailScanner Aug. 22, 2003

Aug. 22, 2003

Our virus detector has just been triggered by a message you sent:- To: arjan(a)isgelukkig.nl 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 been delivered. Consider renaming the files or putting them into a "zip" file to avoid this constraint. 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) -- Moerstaal MailScanner

1 0

You can order Anti-depressants, weightlosmeds, and pain relief medsonline with no prescriiption za g nnhcqisa
by Devon Stephenson Aug. 22, 2003

Aug. 22, 2003

1 0

Re: g_ascii_strtod/snprintf and Python
by Alexander Larsson Aug. 22, 2003

Aug. 22, 2003

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 > Agreement. > > --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 alexl(a)redhat.com alla(a)lysator.liu.se 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!

1 0

cooperative generators
by Clark C. Evans Aug. 21, 2003

Aug. 21, 2003

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 [1] 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 multitasking contexts. 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: buildPage | buildHeader | | writeTopOfHeader | | writeMetaKeywords | | queryLDAP* (returns iteratable keyword sequence) | | writeRestOfHeader | buildNavigator | | writeTopOfNavigator | | writeNavigatorRows | | queryLDAP* (to get items for the Navigator) | | writeRestOfNavigator | buildGrid | | writeTopOfGrid | | writeRows | | queryDatabase* (returns sequence of rows ) | writeFooter 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 [1] 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) yield parentGenerator for x in parentGenerator: # do something with X yeild parentGenerator 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. Kind Regards, Clark

5 5

Virus in Mail entdeckt / Virus found in the message
by viruscheck＠rz.uni-osnabrueck.de Aug. 21, 2003

Aug. 21, 2003

>>> Absender <<< Diese Nachricht wurde automatisch generiert von: Mail Scanner, Universitaet Osnabrueck, Rechenzentrum E-Mail: VirusCheck(a)rz.uni-osnabrueck.de >>> Informationen <<< Der Mail Scanner hat eine infizierte Mail entdeckt, die Ihre Absender-Adresse traegt. Diese Mail ist *nicht* an die Empfaenger weitergeleitet worden. Absender: <python-dev(a)python.org> Empfaenger: <rpesch(a)ispa.uni-vechta.de> >>> Virus-Beschreibung (englisch) <<< Email data: MessageID: <200308211447.h7LEliTA000632(a)mail-in-1.serv.uni-osnabrueck.de> From: <python-dev(a)python.org> To: <rpesch(a)ispa.uni-vechta.de> Cc: 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 E-Mail: VirusCheck(a)rz.uni-osnabrueck.de

1 0

Your last email to this domain was deleted
by Ian D. Mead/IDM Computer Solutuions Aug. 20, 2003

Aug. 20, 2003

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 attachment. 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. Thank you. Ian

1 0

Virus found in message from you!
by kavkeeper＠ns1.epcwc.com Aug. 20, 2003

Aug. 20, 2003

Kaspersky Anti-Virus 4.0.0 reports a problem: you sent a message with a virus ! In the following message: ---------------------- From:python-dev@python.org To:tluu@epcusa.com ---------------------- Please check your computer with Kaspersky Antivirus Scanner!

1 0

Your message to viewcvs awaits moderator approval
by viewcvs-bounces＠lyra.org Aug. 20, 2003

Aug. 20, 2003

Your mail to 'viewcvs' with the subject Re: Details 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: http://mailman.lyra.org/mailman/confirm/viewcvs/b80d5ade1a6e76bc5863eedbfc4…

1 0

Warning: could not send message for past 4 hours
by Mail Delivery Subsystem Aug. 20, 2003

Aug. 20, 2003

********************************************** ** 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 [68.50.248.199] ----- The following addresses had transient non-fatal errors ----- <cc(a)dd.org> ----- 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

1 0