From mwh@python.net  Thu Jun  7 13:58:49 2001
From: mwh@python.net (Michael Hudson)
Date: Thu, 7 Jun 2001 13:58:49 +0100 (BST)
Subject: python-dev summary 2001-05-24 - 2001-06-07
Message-ID: <mailman.992002201.15209.clpa-moderators@python.org>

 This is a summary of traffic on the python-dev mailing list between
 May 24 and Jun 7 (inclusive) 2001.  It is intended to inform the
 wider Python community of ongoing developments.  To comment, just
 post to python-list@python.org or comp.lang.python in the usual
 way. Give your posting a meaningful subject line, and if it's about a
 PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
 iteration) All python-dev members are interested in seeing ideas
 discussed by the community, so don't hesitate to take a stance on a
 PEP if you have an opinion.

 This is the ninth summary written by Michael Hudson.
 Summaries are archived at:

  <http://starship.python.net/crew/mwh/summaries/>

   Posting distribution (with apologies to mbm)

   Number of articles in summary: 305

    50 |                                                 [|]
       |                                                 [|]
       |                                                 [|]
       |                                                 [|]
    40 |                                                 [|]
       |                                                 [|]
       |                                                 [|]
       |                         [|] [|]                 [|]
    30 |                         [|] [|] [|]             [|]
       |                         [|] [|] [|]             [|]
       |                         [|] [|] [|]             [|]
       |                         [|] [|] [|]             [|]
    20 |                         [|] [|] [|]             [|]
       | [|]             [|] [|] [|] [|] [|]         [|] [|]
       | [|]             [|] [|] [|] [|] [|]         [|] [|]
       | [|] [|]     [|] [|] [|] [|] [|] [|] [|]     [|] [|] [|]
    10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]     [|] [|] [|]
       | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
       | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
     0 +-018-014-011-014-020-019-034-035-032-014-008-020-051-015
        Thu 24| Sat 26| Mon 28| Wed 30| Fri 01| Sun 03| Tue 05|
            Fri 25  Sun 27  Tue 29  Thu 31  Sat 02  Mon 04  Wed 06

 Another busy-ish fortnight.  I've been in Exam Hell(tm) and am
 writing this when hungover, this so summary might be a bit sketchier
 than normal.  Apologies in advance.


    * strop vs. string *

 Greg Stein leapt up to defend the slated-to-be-deprecated strop
 module by pointing out that it's functions work on any object that
 supports the buffer API, whereas the 1.6-era string.py only works
 with objects that sprout the right methods:

  <http://mail.python.org/pipermail/python-dev/2001-May/015001.html>

 The discussion quickly degenerated into the usual griping about the
 fact that the buffer API is flawed and undocumented and not really
 well understood by many people.


    * Special-casing "O" *

 As a followup to the discussion mentioned in the last summary, Martin
 von Loewis posted a patch to sf enabling functions written in C that
 expect zero or one object arguments to dispense with the time wasting
 call to PyArg_ParseTuple:

  <http://mail.python.org/pipermail/python-dev/2001-May/015020.html>

 The first version of the patch was criticized for being overly
 general, and for not being general enough <wink>.  It seems the
 forces of simplicity have won, but I don't think the patch has been
 checked in yet.


    * the late, unlamented, yearly list.append panic *

 Tim Peters posted

    c.l.py has rediscovered the quadratic-time worst-case behavior of
    list.append().

  <http://mail.python.org/pipermail/python-dev/2001-May/015027.html>

 And then ameliorated the worst-case behaviour.  So that one was easy.


    * making dicts ... *

 You might think that as dictionaries are so central to Python that
 their implementation would be bulletproof and one the areas of the
 source that would be least likely to change.

 This might be true *now*; Tim Peters seems to have spent most of the
 last fortnight implementing performance improvements one after the
 other and fixing core-dumping holes in the implementation pointed out
 by Michael Hudson.

 The first improvement was to "using polynomial division instead of
 multiplication for generating the probe sequence, as a way to get all
 the bits of the hash code into play."

  <http://mail.python.org/pipermail/python-dev/2001-May/015045.html>

 If you don't understand what that means, ignore it because Tim came
 up with a more radical rewrite:

  <http://mail.python.org/pipermail/python-dev/2001-May/015130.html>

 which seems to be a win, but sadly removes the shock of finding
 comments about Galois theory in dictobject.c...  Most of the
 discussion in the thread following Tim's patch was about whether we
 need 128-bit floats or ints, which is another way of saying everyone
 liked it :-)  This one hasn't been checked in either.


    * ... and breaking dicts *

 Inspired by a post to comp.lang.python by Wolfgang Lipp and driven
 slightly insane by revision, Michael Hudson posted a short program
 that used a hole in the dict implementation to trigger a core dump:

  <http://mail.python.org/pipermail/python-dev/2001-June/015173.html>

 This got fixed, so he did it again:

  <http://mail.python.org/pipermail/python-dev/2001-June/015208.html>

 The cause of both problems was C code assuming things about
 dictionaries remained the same across calls to code that ended up
 executing arbitrary Python code, which could mutate the dict exactly
 as much as it pleased, which in turn caused pointers to dangle.  This
 problem has a history in Python; the .sort() method on lists has to
 fight the same issues.

 These holes have been plugged, although it is still possible to crash
 Python with exceptionally contrived code:

  <http://mail.python.org/pipermail/python-dev/2001-June/015239.html>

 There's another approach, which is was the .sort() method uses:

    >>> list = range(10)
    >>> def c(x,y):
    ...     del list[:]
    ...     return cmp(x, y)
    ...
    >>> list.sort(c)
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "<stdin>", line 2, in c
    TypeError: a list cannot be modified while it is being sorted

 The .sort() method magically changes the type of the list being
 sorted to one that doesn't support mutation while it's sorting the
 list.  This approach would have some merit to use with dictionaries
 too; for one thing we could lose all the contrived code in
 dictobject.c protecting against this sort of silliness...


    * arbitrary radix formatting *

 Greg Wilson made a plea for the addition of a "%b" formatting
 operator to display integers in binary, e.g:

    >>> print "%d %x %o %b"%(10,10,10,10)
    10 a 12 1010

  <http://mail.python.org/pipermail/python-dev/2001-May/015111.html>

 There was general support for the idea, but Tim Peters and Greg Ewing
 pointed out that it would be neater to invent a general format code
 that would enable one to format an integer into an arbitrary base, so
 that

    >>>> int("1111", 7)
    400

 has an inverse at long last.  But no-one could think of a spelling
 that wasn't in general use, and the discussion died :-(.


    * quick poll *

 Guido asked if anyone would object violently to the builtin
 conversion functions becoming type objects on the descr-branch:

  <http://mail.python.org/pipermail/python-dev/2001-June/015256.html>

 in analogy to class objects.  There was general support and only a
 few concerns, and the changes have begun to hit descr-branch.  I'm
 sure I'm not the only one who wishes they had the time to understand
 what is going on in there...

Cheers,
M.



From alessandro.manotti@bfeurope.com  Fri Jun  8 12:43:18 2001
From: alessandro.manotti@bfeurope.com (MANOTTI Alessandro)
Date: Fri, 8 Jun 2001 13:43:18 +0200
Subject: B.Y.P. Server
Message-ID: <mailman.992002201.15213.clpa-moderators@python.org>

Dear all,

	I created a very special server:

	I'm creating a software, written in Python, to mix the 
	advantages of Internet (server web) and a client/server
	 structure. Traditional web servers use a "state-less" system,
	 in-fact when a browser requires some information to the server,
	 in the server machine will be launched a CGI, or PHP/ASP (etc...) 
	script and, when the request was satisfied, the connection can be
	 considered "terminated": the programs (maybe CGI) which
	 answered were terminated.
	I'm creating a system in which the server launches some 
	threads (programs which substitute the CGI) and they remain
	 active until the client exits from the application or with a
	 time-out. I'm  creating the server thinking to Macromedia Flash 5 
	as client (that's why I'm writing to you)
	(with this software, I can create very actractive programs, 
	just like a beautiful and very functional graphic terminal client).
	With my project I intend to join the advantages of an
	 Intranet/Extranet/Internet system with the advantages of a 
	client/server system.
	One of the major targets is to simplify the server side 
	programming: in-fact I wish let youcreate a program with the 
	same technics that you use to create a local oriented software!

	Of course, there are a lot of things to do,
	but I installed this system in my company (a big company)
	and it functions very well! Furthermore, is very simple to write
	programs! (There are not the difficults that you can encounter
	creating programs for standard web servers!!!)

	Now the biggest problem I have, is maintain updated the 
	documentation!

	This project is licenced under GPL.

	If you are interested about my project (my server runs in a 24x7
cycle,
	since it implements a dynamic loading of new modules, daemons,
	server routines) please send me an e-mail or visit my site!

	Thank you very much for the attention you gave me!!!

	Alessandro Manotti





manotti@bigfoot.com
http://members.xoom.it/bypserver




From bh@intevation.de  Fri Jun  8 18:16:19 2001
From: bh@intevation.de (Bernhard Herzog)
Date: 08 Jun 2001 19:16:19 +0200
Subject: MapIt! 1.0 - Webapplication for Rastermaps
Message-ID: <mailman.992040540.10454.clpa-moderators@python.org>

  MapIt! 1.0

  http://www.mapit.de/


MapIt! is a web-application that lets you navigate raster-maps through
your web-browser and lets you zoom in and out and select objects and
object classes that are identified on the map.

MapIt! is implemented in Python and uses the Python Imaging Library.

MapIt! is Free Software licensed under LGPL (GNU Library General Public
License).

MapIt! can be integrated with a web-server in various ways: As
CGI-script, via fast CGI (Apache and Roxen Challenger) or with
mod_python (Apache).

MapIt! runs under various Unices (e.g. Linux) and some Windows versions
(we tested with Windows 98 and NT4).


From Anthony@COMPUTRONIX.com  Fri Jun  8 23:30:56 2001
From: Anthony@COMPUTRONIX.com (Anthony Tuininga)
Date: Fri, 8 Jun 2001 16:30:56 -0600
Subject: cx_Oracle
Message-ID: <mailman.992040540.10455.clpa-moderators@python.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F06A.AF21C740
Content-Type: text/plain;
	charset="iso-8859-1"

By popular demand, I have created a Win32 binary for Python 2.1 in addition
to the one already present for Python 2.0. You can find it at the following
address: www.computronix.com/utilities

For those who are wondering what cx_Oracle is, it is a module which provides
a Python DB-API 2.0 compliant method for accessing Oracle databases. Please
see www.computronix.com/utilities/ReadMe.txt for more information.

Anthony




------_=_NextPart_001_01C0F06A.AF21C740
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>cx_Oracle</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">By popular demand, I have created a =
Win32 binary for Python 2.1 in addition to the one already present for =
Python 2.0. You can find it at the following address: =
www.computronix.com/utilities</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For those who are wondering what =
cx_Oracle is, it is a module which provides a Python DB-API 2.0 =
compliant method for accessing Oracle databases. Please see =
www.computronix.com/utilities/ReadMe.txt for more =
information.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Anthony</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C0F06A.AF21C740--


From bh@intevation.de  Sat Jun  9 21:26:33 2001
From: bh@intevation.de (Bernhard Herzog)
Date: 09 Jun 2001 22:26:33 +0200
Subject: Sketch 0.6.11 - A vector drawing program
Message-ID: <mailman.992157361.27893.clpa-moderators@python.org>

        Sketch 0.6.11 - A vector drawing program


Sketch is a vector drawing program for Linux and other unices.  It's
intended to be a flexible and powerful tool for illustrations, diagrams
and other purposes.

It has advanced features like gradients, text along a path and clip
masks and is fully scriptable due to its implementation in a combination
of Python and C.

More information, sources and binaries are available at the website:
        http://sketch.sourceforge.net/


Summary of the Changes since 0.6.10:
=20
 * Fix another Python 2.1 related bug

 * Updated Spanish translation by Esteban Manchado Vel=E1zquez

 * a few other bug fixes.


Sketch is released under the GNU Library General Public License.




From akuchlin@mems-exchange.org  Mon Jun 11 16:58:16 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon, 11 Jun 2001 11:58:16 -0400
Subject: Quixote 0.3 released
Message-ID: <mailman.992279041.25730.clpa-moderators@python.org>

Version 0.3 of the Quixote Web development toolkit is now available.
Quixote uses a Python package to store all the code and HTML for a
Web-based application.  PTL, Python Template Language, is used to mix
HTML with Python code; the basic syntax looks just like Python, but
expressions are converted to strings and appended to the output.

Notable changes in this version are: 

	* Now supports Python 2.1.

	* Names of the form __*__ are reserved for Python, and 2.1 is
	  beginning to enforce this rule.  Accordingly the Quixote special
	  methods have been renamed:
	      __access__     -> _q_access
	      __exports__    -> _q_exports
	      __getname__    -> _q_getname
	      index          -> _q_index
	
	* Massive changes to quixote.publisher and quixote.config, to make
	  the publishing loop more flexible and more easily changed by
	  applications.  For example, it's now possible to catch the
	  ZODB's ConflictErrors and retry an operation.
	
	* quixote.publish can now gzip-compress its output if the browser
	  claims to support it.  Only the 'gzip' and 'x-gzip' content
	  encodings are supported; 'deflate' isn't because we couldn't get
	  it to work reliably.  Compression can be enabled by setting the
	  'compress_pages' config option to true.

As usual, some of these changes are incompatible with the previous
version.

The Quixote home page is at:
        http://www.mems-exchange.org/software/python/quixote/

The code can be downloaded from:
        http://www.mems-exchange.org/software/files/quixote/

Discussion of Quixote occurs on the quixote-users mailing list:
        http://www.mems-exchange.org/mailman/listinfo/quixote-users/

--amk


From akuchlin@mems-exchange.org  Mon Jun 11 21:19:53 2001
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Mon, 11 Jun 2001 16:19:53 -0400
Subject: New ZODB distribution release
Message-ID: <mailman.992380331.21323.clpa-moderators@python.org>

I've made a new packaging of the ZODB from Digital Creations.  This
release contains the code from Zope 2.3.2 and the most recent ZEO
release, ZEO 1.0beta3.

The release is available from:
    http://www.amk.ca/files/zodb/

The full list of changes in this release runs as follows:

* Removed top-level setup.py, and changed the README accordingly.
* Resynced with ZEO 1.0b3
* Resynced with BerkeleyStorage 1.0b2
* Resynced with Zope 2.3.2.
* Removed SearchIndex and Catalog packages; they're tangential to
  the ZODB itself. 

--amk


From ngps@post1.com  Wed Jun 13 16:35:52 2001
From: ngps@post1.com (Ng Pheng Siong)
Date: Wed, 13 Jun 2001 23:35:52 +0800
Subject: pgnotify 0.1
Message-ID: <mailman.992510340.9023.clpa-moderators@python.org>

Hello,

I am pleased to announce the release of pgnotify 0.1. 

pgnotify is a PostgreSQL client-side asynchronous notification handler for
Python.

Typically, asynchronous notification is used to communicate the message "I
changed this table, take a look at it to see what's new" from one PostgreSQL 
client to other interested PostgreSQL clients. 


pgnotify is developed on this platform:
- FreeBSD 4.0
- Python 2.1
- PostgreSQL 7.1.1
- PyGreSQL 3.2


At present, pgnotify works with PyGreSQL only. It should work with PoPy and
psycopg when those modules provide Pythonic interfaces to additional
necessary PostgreSQL client-side functions, as described in the README.


Get pgnotify here:

    http://www.post1.com/home/ngps/pgnotify


As usual, feedback is welcome.


-- 
Ng Pheng Siong <ngps@post1.com> * http://www.post1.com/home/ngps

Quidquid latine dictum sit, altum viditur.


From jsaenz@wm.lc.ehu.es  Wed Jun 13 17:55:39 2001
From: jsaenz@wm.lc.ehu.es (Jon Saenz)
Date: Wed, 13 Jun 2001 18:55:39 +0200 (MET DST)
Subject: PyClimate 1.1. Analysis of atmospheric and oceanic data
Message-ID: <mailman.992510340.9024.clpa-moderators@python.org>

Announce: PyClimate 1.1, 13 June 2001

We present version 1.1 of our package PyClimate: http://www.pyclimate.org

It is dedicated to the analysis of atmospheric and oceanic data sets
using Python. It makes heavy use of NumPy and some of our own
C extensions to speed up the code.

It is distributed according to the GNU General Public License Version 2
(it is free).

The updates from version 1.0 to 1.1 comprise:
a) Some minor bugs corrected.
b) Addition of functions and classes to perform Canonical 
   Correlation Analysis (CCA) in the EOF space.
c) Additional functions and scaling conventions for EOFs. The interface
   for EOFs and SVD is much easier than previous version. The routines
   accept arbitrarily shaped fields for input and reshape
   accordingly their outputs.
d) Updated algorithms (much faster) for the random selection of
   subsamples in Monte Carlo tests on eigenvectors.
e) New algorithms for differential operators on the sphere. Current 
   version handles periodic boundary conditions in longitude and
   arbitrarily shaped scalar or vector fields organized according to
   COARDS Conventions. Current version handles fields
   arranged as (T,Z,lat,lon).
f) Exception strings have been converted to classes.
g) The reference file has grown a lot. It is not currently distributed with
   the package, but can still be accessed from the WEB server.

We have made our best to make all those changes backwards compatible.
In some cases (exception strings -> classes), they may break some code, 
but we are enforced to make those changes due to Python's new designs.

We would appreciate feedback by users.

Enjoy ;-)


Jon Saenz, jsaenz@wm.lc.ehu.es
Jesus Fernandez, chus@wm.lc.ehu.es
Juan Zubillaga, juan@zubi.net


       <P><A HREF="http://www.pyclimate.org">PyClimate 1.1</A> - 
	Analysis of Atmospheric and Oceanic Data Sets using Python.
        (13-Jun-01)</P>



From tim@digicool.com  Thu Jun 14 17:49:07 2001
From: tim@digicool.com (Tim Peters)
Date: Thu, 14 Jun 2001 12:49:07 -0400
Subject: PEP 255: Simple Generators
Message-ID: <mailman.992552881.11267.clpa-moderators@python.org>

You can view an HTML version of PEP 255 here:

    http://python.sourceforge.net/peps/pep-0255.html

Discussion should take place primarily on the Python Iterators list:

    mailto:python-iterators@lists.sourceforge.net

If replying directly to this message, please remove (at least) Python-Dev
and Python-Announce.


PEP: 255
Title: Simple Generators
Version: $Revision: 1.3 $
Author: nas@python.ca (Neil Schemenauer),
    tim.one@home.com (Tim Peters),
    magnus@hetland.org (Magnus Lie Hetland)
Discussion-To: python-iterators@lists.sourceforge.net
Status: Draft
Type: Standards Track
Requires: 234
Created: 18-May-2001
Python-Version: 2.2
Post-History: 14-Jun-2001


Abstract

    This PEP introduces the concept of generators to Python, as well
    as a new statement used in conjunction with them, the "yield"
    statement.


Motivation

    When a producer function has a hard enough job that it requires
    maintaining state between values produced, most programming languages
    offer no pleasant and efficient solution beyond adding a callback
    function to the producer's argument list, to be called with each value
    produced.

    For example, tokenize.py in the standard library takes this approach:
    the caller must pass a "tokeneater" function to tokenize(), called
    whenever tokenize() finds the next token.  This allows tokenize to be
    coded in a natural way, but programs calling tokenize are typically
    convoluted by the need to remember between callbacks which token(s)
    were seen last.  The tokeneater function in tabnanny.py is a good
    example of that, maintaining a state machine in global variables, to
    remember across callbacks what it has already seen and what it hopes to
    see next.  This was difficult to get working correctly, and is still
    difficult for people to understand.  Unfortunately, that's typical of
    this approach.

    An alternative would have been for tokenize to produce an entire parse
    of the Python program at once, in a large list.  Then tokenize clients
    could be written in a natural way, using local variables and local
    control flow (such as loops and nested if statements) to keep track of
    their state.  But this isn't practical:  programs can be very large, so
    no a priori bound can be placed on the memory needed to materialize the
    whole parse; and some tokenize clients only want to see whether
    something specific appears early in the program (e.g., a future
    statement, or, as is done in IDLE, just the first indented statement),
    and then parsing the whole program first is a severe waste of time.

    Another alternative would be to make tokenize an iterator[1],
    delivering the next token whenever its .next() method is invoked.  This
    is pleasant for the caller in the same way a large list of results
    would be, but without the memory and "what if I want to get out early?"
    drawbacks.  However, this shifts the burden on tokenize to remember
    *its* state between .next() invocations, and the reader need only
    glance at tokenize.tokenize_loop() to realize what a horrid chore that
    would be.  Or picture a recursive algorithm for producing the nodes of
    a general tree structure:  to cast that into an iterator framework
    requires removing the recursion manually and maintaining the state of
    the traversal by hand.

    A fourth option is to run the producer and consumer in separate
    threads.  This allows both to maintain their states in natural ways,
    and so is pleasant for both.  Indeed, Demo/threads/Generator.py in the
    Python source distribution provides a usable synchronized-communication
    class for doing that in a general way.  This doesn't work on platforms
    without threads, though, and is very slow on platforms that do
    (compared to what is achievable without threads).

    A final option is to use the Stackless[2][3] variant implementation of
    Python instead, which supports lightweight coroutines.  This has much
    the same programmatic benefits as the thread option, but is much more
    efficient.  However, Stackless is a controversial rethinking of the
    Python core, and it may not be possible for Jython to implement the
    same semantics.  This PEP isn't the place to debate that, so suffice it
    to say here that generators provide a useful subset of Stackless
    functionality in a way that fits easily into the current CPython
    implementation, and is believed to be relatively straightforward for
    other Python implementations.

    That exhausts the current alternatives.  Some other high-level
    languages provide pleasant solutions, notably iterators in Sather[4],
    which were inspired by iterators in CLU; and generators in Icon[5], a
    novel language where every expression "is a generator".  There are
    differences among these, but the basic idea is the same:  provide a
    kind of function that can return an intermediate result ("the next
    value") to its caller, but maintaining the function's local state so
    that the function can be resumed again right where it left off.  A
    very simple example:

        def fib():
            a, b = 0, 1
            while 1:
                yield b
                a, b = b, a+b

    When fib() is first invoked, it sets a to 0 and b to 1, then yields b
    back to its caller.  The caller sees 1.  When fib is resumed, from its
    point of view the yield statement is really the same as, say, a print
    statement:  fib continues after the yield with all local state intact.
    a and b then become 1 and 1, and fib loops back to the yield, yielding
    1 to its invoker.  And so on.  From fib's point of view it's just
    delivering a sequence of results, as if via callback.  But from its
    caller's point of view, the fib invocation is an iterable object that
    can be resumed at will.  As in the thread approach, this allows both
    sides to be coded in the most natural ways; but unlike the thread
    approach, this can be done efficiently and on all platforms.  Indeed,
    resuming a generator should be no more expensive than a function call.

    The same kind of approach applies to many producer/consumer functions.
    For example, tokenize.py could yield the next token instead of invoking
    a callback function with it as argument, and tokenize clients could
    iterate over the tokens in a natural way:  a Python generator is a kind
    of Python iterator[1], but of an especially powerful kind.


Specification

    A new statement is introduced:

        yield_stmt:    "yield" expression_list

    "yield" is a new keyword, so a future statement[8] is needed to phase
    this in.  [XXX spell this out]

    The yield statement may only be used inside functions.  A function that
    contains a yield statement is called a generator function.

    When a generator function is called, the actual arguments are bound to
    function-local formal argument names in the usual way, but no code in
    the body of the function is executed.  Instead a generator-iterator
    object is returned; this conforms to the iterator protocol[6], so in
    particular can be used in for-loops in a natural way.  Note that when
    the intent is clear from context, the unqualified name "generator" may
    be used to refer either to a generator-function or a generator-
    iterator.

    Each time the .next() method of a generator-iterator is invoked, the
    code in the body of the generator-function is executed until a yield
    or return statement (see below) is encountered, or until the end of
    the body is reached.

    If a yield statement is encountered, the state of the function is
    frozen, and the value of expression_list is returned to .next()'s
    caller.  By "frozen" we mean that all local state is retained,
    including the current bindings of local variables, the instruction
    pointer, and the internal evaluation stack:  enough information is
    saved so that the next time .next() is invoked, the function can
    proceed exactly as if the yield statement were just another external
    call.

    A generator function can also contain return statements of the form:

        "return"

    Note that an expression_list is not allowed on return statements
    in the body of a generator (although, of course, they may appear in
    the bodies of non-generator functions nested within the generator).

    When a return statement is encountered, nothing is returned, but a
    StopIteration exception is raised, signalling that the iterator is
    exhausted.   The same is true if control flows off the end of the
    function.  Note that return means "I'm done, and have nothing
    interesting to return", for both generator functions and non-generator
    functions.


Example

        # A binary tree class.
        class Tree:

            def __init__(self, label, left=None, right=None):
                self.label = label
                self.left = left
                self.right = right

            def __repr__(self, level=0, indent="    "):
                s = level*indent + `self.label`
                if self.left:
                    s = s + "\n" + self.left.__repr__(level+1, indent)
                if self.right:
                    s = s + "\n" + self.right.__repr__(level+1, indent)
                return s

            def __iter__(self):
                return inorder(self)

        # Create a Tree from a list.
        def tree(list):
            n = len(list)
            if n == 0:
                return []
            i = n / 2
            return Tree(list[i], tree(list[:i]), tree(list[i+1:]))

        # A recursive generator that generates Tree leaves in in-order.
        def inorder(t):
            if t:
                for x in inorder(t.left):
                    yield x
                yield t.label
                for x in inorder(t.right):
                    yield x

        # Show it off: create a tree.
        t = tree("ABCDEFGHIJKLMNOPQRSTUVWXYZ")
        # Print the nodes of the tree in in-order.
        for x in t:
            print x,
        print

        # A non-recursive generator.
        def inorder(node):
            stack = []
            while node:
                while node.left:
                    stack.append(node)
                    node = node.left
                yield node.label
                while not node.right:
                    try:
                        node = stack.pop()
                    except IndexError:
                        return
                    yield node.label
                node = node.right

        # Exercise the non-recursive generator.
        for x in t:
            print x,
        print


Q & A

    Q. Why a new keyword?  Why not a builtin function instead?

    A. Control flow is much better expressed via keyword in Python, and
       yield is a control construct.  It's also believed that efficient
       implementation in Jython requires that the compiler be able to
       determine potential suspension points at compile-time, and a new
       keyword makes that easy.


Reference Implementation

    A preliminary patch against the CVS Python source is available[7].


Footnotes and References

    [1] PEP 234, http://python.sf.net/peps/pep-0234.html
    [2] http://www.stackless.com/
    [3] PEP 219, http://python.sf.net/peps/pep-0219.html
    [4] "Iteration Abstraction in Sather"
        Murer , Omohundro, Stoutamire and Szyperski
        http://www.icsi.berkeley.edu/~sather/Publications/toplas.html
    [5] http://www.cs.arizona.edu/icon/
    [6] The concept of iterators is described in PEP 234
        http://python.sf.net/peps/pep-0234.html
    [7] http://python.ca/nas/python/generator.diff
    [8] http://python.sf.net/peps/pep-0236.html


Copyright

    This document has been placed in the public domain.



From guido@digicool.com  Thu Jun 14 18:30:42 2001
From: guido@digicool.com (Guido van Rossum)
Date: Thu, 14 Jun 2001 13:30:42 -0400
Subject: Python 2.0.1c1 - GPL-compatible release candidate
Message-ID: <mailman.992552881.11268.clpa-moderators@python.org>

With a sigh of relief I announce Python 2.0.1c1 -- the first Python
release in a long time whose license is fully compatible with the GPL:

    http://www.python.org/2.0.1/

I thank Moshe Zadka who did almost all of the work to make this a
useful bugfix release, and then went incommunicado for several weeks.
(I hope you're OK, Moshe!)

Note that this is a release candidate.  We don't expect any problems,
but we're being careful nevertheless.  We're planning to do the final
release of 2.0.1 a week from now; expect it to be identical to the
release candidate except for some dotted i's and crossed t's.

Python 2.0 users should be able to replace their 2.0 installation with
the 2.0.1 release without any ill effects; apart from the license
change, we've only fixed bugs that didn't require us to make feature
changes.  The SRE package (regular expression matching, used by the
"re" module) was brought in line with the version distributed with
Python 2.1; this is stable feature-wise but much improved bug-wise.

For the full scoop, see the release notes on SourceForge:

    http://sourceforge.net/project/shownotes.php?release_id=39267

Python 2.1 users can ignore this release, unless they have an urgent
need for a GPL-compatible Python version and are willing to downgrade.
Rest assured that we're planning a bugfix release there too: I expect
that Python 2.1.1 will be released within a month, with the same
GPL-compatible license.  (Right, Thomas?)

We don't intend to build RPMs for 2.0.1.  If someone else is
interested in doing so, we can link to them.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From djc@object-craft.com.au  Sun Jun 17 14:32:01 2001
From: djc@object-craft.com.au (Dave Cole)
Date: 17 Jun 2001 23:32:01 +1000
Subject: csv-0.3 released
Message-ID: <mailman.992813221.29993.clpa-moderators@python.org>

I have just started fiddling around with building modules on NT so
decided to convert my csv module to distutils.  It seems to be
working.

So for all of you NT heads who were just hanging out for a fast CSV
parser in Python - here it is:

        http://www.object-craft.com.au/projects/csv/

For people who do not have a C compiler I have put the binary up here:

        http://www.object-craft.com.au/projects/csv/csv.pyd

- Dave

-- 
http://www.object-craft.com.au



From andymac@bullseye.apana.org.au  Sun Jun 17 09:34:12 2001
From: andymac@bullseye.apana.org.au (Andrew MacIntyre)
Date: Sun, 17 Jun 2001 18:34:12 +1000 (EST)
Subject: ANN: port of Python 2.1 to OS/2+EMX
In-Reply-To: <Pine.OS2.4.32.0104260151030.6074-100000@central>
Message-ID: <mailman.992813221.29994.clpa-moderators@python.org>

I have uploaded a port of Python 2.1 to the incoming directories of
the Hobbes (http://hobbes.nmsu.edu) and LEO (http://archiv.leo.org/) OS/2
software archives.

This port supports the case sensitive module import semantics
introduced in Python 2.1 for case-insensitive but case preserving
file systems (such as used by the MS-Windows family of OSes, as well
as OS/2).

The distributed archives are:
  python-2.1-os2emx-bin-010617.zip (binary installation package, 2.9MB)
  python-2.1-os2emx-src-010617.zip (source patches and makefiles, 108kB)

More info available at http://www.pcug.org.au/~andymac/software.html;
the above archives are also available there if you can't find them
at Hobbes or LEO.

OS/2 users enjoy!

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andrew.macintyre@aba.gov.au    (work) | Snail: PO Box 370
        andymac@bullseye.apana.org.au  (play) |        Belconnen  ACT  2616
        andymac@pcug.org.au           (play2) |        Australia



From gritsch@iue.tuwien.ac.at  Mon Jun 18 22:38:25 2001
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Mon, 18 Jun 2001 23:38:25 +0200
Subject: ANN: VideoCapture-0.1 - video device access (e.g. USB webcams)
Message-ID: <mailman.992921580.28726.clpa-moderators@python.org>

VideoCapture-0.1
================

URL:
----
http://stud4.tuwien.ac.at/~e9326522/VideoCapture/

What it is:
-----------
VideoCapture is a Python extension for Win32 which makes it possible to
access the video device (e.g. a USB webcam).  It consists of a low-level
native module (vidcap.pyd) and a high-level module written in Python
(VideoCapture.py) which should be used solely.

Contact:
--------
Markus Gritsch (gritsch@iue.tuwien.ac.at)


Enjoy and have fun!



<P><A
HREF="http://stud4.tuwien.ac.at/~e9326522/VideoCapture/">VideoCapture-0.1</A
> - A Win32 Python Extension for Accessing the Video Device (e.g. a USB
WebCam).  (18-Jun-2001)




From beazley@cs.uchicago.edu  Tue Jun 19 00:57:33 2001
From: beazley@cs.uchicago.edu (David Beazley)
Date: Mon, 18 Jun 2001 18:57:33 -0500 (CDT)
Subject: ANN: Introducing PLY-1.0 (Python Lex-Yacc)
Message-ID: <mailman.992921580.28727.clpa-moderators@python.org>

June 18, 2001

		 Announcing :  PLY-1.0 (Python Lex-Yacc)

		  http://systems.cs.uchicago.edu/ply

Just when you thought it was safe, I'm pleased to announce the availability
of an entirely new Python parser construction tool.

PLY is a 100% Python implementation of the common parsing tools lex
and yacc.  Although several other parsing tools are available for
Python, there are several reasons why you might want to consider PLY:

 -  The tools are very closely modeled after traditional lex/yacc.
    If you know how to use these tools in C, you will find PLY
    to be similar.

 -  PLY provides *very* extensive error reporting and diagnostic 
    information to assist in parser construction.  The original
    implementation was developed for instructional purposes.  As
    a result, the system tries to identify the most common types
    of errors made by novice users.  

 -  PLY provides full support for empty productions, error recovery,
    precedence rules, and moderately ambiguous grammars.

 -  Parsing is based on LR-parsing which is fast, memory efficient, 
    better suited to large grammars, and which has a number of nice
    properties when dealing with syntax errors and other parsing problems.
    Currently, PLY builds its parsing tables using the SLR algorithm which 
    is slightly weaker than LALR(1) which is used in traditional yacc. 

 -  Like John Aycock's excellent SPARK toolkit, PLY uses Python 
    reflection to build lexers and parsers.  This greatly simplifies 
    the task of parser construction since it reduces the number of files
    and eliminates the need to run a separate lex/yacc tool before
    running your program. 

 -  PLY can be used to build parsers for large programming languages.
    Although it is not ultra-fast due to its Python implementation,
    PLY can be used to parse grammars consisting of several hundred
    rules (as might be found for a language like C).  The lexer and LR 
    parser are also reasonably efficient when parsing normal
    sized programs.

The original version of PLY was developed for an Introduction to
Compilers course where students used it to build a compiler for a
simple Pascal-like language.  Their compiler had to include lexical
analysis, parsing, type checking, type inference, nested scoping, and
generation of assembly code for the SPARC processor.  Because of this,
the current implementation has been extensively tested and debugged.
In addition, most of the API and error checking facilities have been
adapted to address common usability problems.

More information about PLY can be obtained on the PLY webpage at:

		  http://systems.cs.uchicago.edu/ply

PLY is freely available and is licensed under the terms of the Lesser
GNU Public License (LGPL).

Cheers,

David Beazley (beazley@cs.uchicago.edu)



From djc@object-craft.com.au  Tue Jun 19 04:28:54 2001
From: djc@object-craft.com.au (Dave Cole)
Date: 19 Jun 2001 13:28:54 +1000
Subject: Sybase module 0.26 released
Message-ID: <mailman.992921580.28728.clpa-moderators@python.org>

What is it:

The Sybase module provides a Python interface to the Sybase relational
database system. The Sybase package supports almost all of the Python
Database API, version 2.0 with extensions.

The module works with Python versions 1.5.2 and later and Sybase
versions 11.0.3 and later.  It is based on the Sybase Client Library
(ct_* API), and the Bulk-Library Client (blk_* API) interfaces.

The 0.20 and later releases are a reimplementation of the module using
a thin C wrapper on the Sybase-CT API, and a Python module to provide
the DB-API functionality.  It is still a work in progress, but should
be good enough for most purposes.

Changes for this release:

- A collection of Sybase example programs was found and converted to
  use the sybasect module.  This highlighted some bugs and many
  omissions.  For the curious the example programs have been included
  in the release.

        array_bind.py  diag_example.py  mult_text.py
        bulkcopy.py    dynamic_cur.py   params.py
        cursor_sel.py  dynamic_ins.py   rpc.py
        cursor_upd.py  example.py       timeout.py

  On the whole I have avoided relying on using Sybase CT library
  callback functions.  The timeout.py example program requires the use
  of a callback.

  Since callbacks cause the Python interpreter to be reentered, you
  cannot compile the module with multi-thread support.  This is
  controlled via the WANT_THREADS #define in sybasect.h

- The ntsetup.py distutils program was merged into the setup.py

- The Buffer type was renamed to DataBuf to avoid type name clashes
  with the Python BufferType.

- Bug was fixed in blk_bind() which was passing Python type object by
  value instead of by reference - oops.

- All of the extension types in the sybasect module are now exported.

- More work has been done on the documentation.

There is very little outstanding programming work for the module.
Most future work will be concentrated on the documentation.

Where can you get it:

        http://www.object-craft.com.au/projects/sybase/

- Dave

-- 
http://www.object-craft.com.au



From B.Y.P.Server2.4.1.Beta  Tue Jun 19 12:11:12 2001
From: B.Y.P.Server2.4.1.Beta (B.Y.P.Server2.4.1.Beta)
Date: Tue, 19 Jun 2001 07:11:12 -0400 (EDT)
Subject: [Application] B.Y.P. Server v.2.4.1. beta
Message-ID: <mailman.992961601.30521.clpa-moderators@python.org>

                      B.Y.P. Server v.2.4.1. beta                       
                      ---------------------------                       

Server to manage this clients over internet!

The site was rebuilt. The target of this project was extended to support
some thin clients developed with a wide range of GUI and languages
(Borland Delphi, Java, Visual Basic, ncurses, KDE, Gnome, etc...)


       URL:  http://OpenSourceDirectory.org/projects/bypserver

   License:  GPL

  Categories:  Net Applications, Server

B.Y.P. Server 2.4.1. Beta (manotti@bigfoot.com)
http://OpenSourceDirectory.org/projects/bypserver

--
<a href="http://OpenSourceDirectory.org/projects/bypserver">B.Y.P.
Server v.2.4.1. beta</a> -- Server to manage this clients over internet!



From ferdinando@ametrano.net  Tue Jun 19 17:16:53 2001
From: ferdinando@ametrano.net (Ferdinando Ametrano)
Date: Tue, 19 Jun 2001 18:16:53 +0200
Subject: [ANN] QuantLib-Python 0.1.9
Message-ID: <mailman.992984880.31629.clpa-moderators@python.org>

QuantLib-Python is the SWIG Python wrap of QuantLib.
QuantLib (http://quantlib.org) is a C++ open source library for 
quantitative finance. Version 0.1.9 of the C++ library and the Python 
extension have been released two weeks ago.

QuantLib license is XFree86-style.

The QuantLib project is aimed to provide a comprehensive software framework 
for quantitative finance. The goal is to provide a standard 
free/open-source library to quantitative analysts and developers for 
modelling, trading, and risk management in real-life. The core library is 
written in C++ and currently exported as a Python module.
Modules are planned for other scripting languages, Excel, MatLab, etc.

QuantLib plans to offer tools that are useful for both practical 
implementation, with features such as market conventions, solvers, PDEs, 
etc., and advanced modelling, e.g., exotic options and interest rate models.

QuantLib is for academics and practitioners. The project is in alpha 
status, not ready for end-users yet but the time is right for major 
contributions to the design and the code base.

Please consider joining one of the available mailing lists:
quantlib-announce 
http://lists.sourceforge.net/mailman/listinfo/quantlib-announce
quantlib-users http://lists.sourceforge.net/mailman/listinfo/quantlib-users
quantlib-cvs http://lists.sourceforge.net/mailman/listinfo/quantlib-cvs

Ferdinando Ametrano (ferdinando@ametrano.net)

<P><A HREF="http://quantlib.org">QuantLib-Python</A> - An open source 
library for quantitative finance. (19-Jun-01)</P>



From mwh@python.net  Fri Jun 22 00:20:17 2001
From: mwh@python.net (Michael Hudson)
Date: Fri, 22 Jun 2001 00:20:17 +0100 (BST)
Subject: python-dev summary 2001-06-07 - 2001-06-21
Message-ID: <mailman.993418261.10448.clpa-moderators@python.org>

 This is a summary of traffic on the python-dev mailing list between
 June 7 and June 21 (inclusive) 2001.  It is intended to inform the
 wider Python community of ongoing developments.  To comment, just
 post to python-list@python.org or comp.lang.python in the usual
 way. Give your posting a meaningful subject line, and if it's about a
 PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
 iteration) All python-dev members are interested in seeing ideas
 discussed by the community, so don't hesitate to take a stance on a
 PEP if you have an opinion.

 This is the tenth summary written by Michael Hudson.
 Summaries are archived at:

  <http://starship.python.net/crew/mwh/summaries/>

   Posting distribution (with apologies to mbm)

   Number of articles in summary: 192

       |                     [|]
       |                     [|]
    30 |                     [|]
       |                     [|]
       |                     [|]
       |                     [|]
       |                     [|]
       |                     [|] [|]
    20 |                     [|] [|]
       |                     [|] [|]                     [|]
       |                     [|] [|]                     [|] [|]
       | [|]                 [|] [|]                     [|] [|]
       | [|]                 [|] [|]                     [|] [|]
       | [|] [|]         [|] [|] [|]                     [|] [|]
    10 | [|] [|]         [|] [|] [|] [|]                 [|] [|]
       | [|] [|]         [|] [|] [|] [|]                 [|] [|]
       | [|] [|]         [|] [|] [|] [|] [|]             [|] [|]
       | [|] [|]         [|] [|] [|] [|] [|]             [|] [|]
       | [|] [|]         [|] [|] [|] [|] [|] [|]     [|] [|] [|]
       | [|] [|]     [|] [|] [|] [|] [|] [|] [|]     [|] [|] [|]
     0 +-019-014-001-003-014-039-026-013-009-004-001-005-023-021
        Thu 07| Sat 09| Mon 11| Wed 13| Fri 15| Sun 17| Tue 19|
            Fri 08  Sun 10  Tue 12  Thu 14  Sat 16  Mon 18  Wed 20

 Quiet fortnight.


    * Adding .decode() method to Unicode *

 Marc-Andre Lemburg asked for opinions on adding a .decode method to
 unicode objects:

  <http://mail.python.org/pipermail/python-dev/2001-June/015346.html>

 He certainly got them; the responses ranged from neutral to negative,
 and there was a surprising amount of hostility in the air.

 The problem (as ever in these matters) seems to be that Python
 currently uses the same type for 8-bit strings and gobs of arbitrary
 data.

 Guido came to the rescue and calmed everyone down:

  <http://mail.python.org/pipermail/python-dev/2001-June/015404.html>

 since when discussion has vanished again.


    * Adding Asian codecs to the core *

 Marc-Andre Lemburg announced that Tamito KAJIYAMA has decided to
 relicense his Japanese codecs with a BSD-style license, enabling them
 to be included in the core:

  <http://mail.python.org/pipermail/python-dev/2001-June/015347.html>

 This is clearly a good thing; the only quibble is that the encodings
 are by their nature rather large, so they will probably go into a
 separate directory in CVS (probably python/dist/encodings/) and not
 go into the source tarball released on python.org.


    * Omit printing newline after newline *

 As readers of comp.lang.python will have noticed, Guido posted:

  <http://mail.python.org/pipermail/python-dev/2001-June/015350.html>

 and retracted:

  <http://mail.python.org/pipermail/python-dev/2001-June/015411.html>

 PEP 259, a proposal for changing the behaviour of the print
 statement.


    * sre "improvements" *

 Gustavo Niemeyer asked if anyone planned to add the "(?(1)blah)" re
 operators to Python:

  <http://mail.python.org/pipermail/python-dev/2001-June/015408.html>

 but Python is not perl and there wasn't much support for making
 regular expressions more baffling than they already are.


    * Generators *

 In a discussion that slobbered across comp.lang.python, python-dev
 and the python-iterators list at sf (and belongs on the latter!)
 there was much talk of PEP 255, Simple Generators.  Most was
 positive; the main dissent was from people that thought it was too
 hard to tell a generator from a regular function (at the source
 level).

 However Guido listened to Tim's repeated claims that this is
 insignificant once you've actually used generators once or twice and
 Pronounced "'def' it is":

  <http://mail.python.org/pipermail/python-dev/2001-June/015500.html>

 and noticed that there are still some issues wrt try/finally blocks.
 However, clever people seem to be thinking about it, so I'm sure the
 problem's days are numbered :-)

 I should also note that the gen-branch has been checked into the
 trunk of CVS.  Woohoo!

Cheers,
M.



From guido@digicool.com  Fri Jun 22 18:12:20 2001
From: guido@digicool.com (Guido van Rossum)
Date: Fri, 22 Jun 2001 13:12:20 -0400
Subject: Python 2.0.1 released!
Message-ID: <mailman.993418261.10449.clpa-moderators@python.org>

I'm happy to announce Python 2.0.1 -- the final release of the first
Python version in a long time whose license is fully compatible with
the GPL:

    http://www.python.org/2.0.1/

I thank Moshe Zadka who did almost all of the work to make this a
useful bugfix release, and then went incommunicado for several weeks.
(I hope you're OK, Moshe!)

Compared to the release candidate, we've fixed a few typos in the
license, tweaked the documentation a bit, and fixed an indentation
error in statcache.py; other than that, the release candidate was
perfect. :-)

Python 2.0 users should be able to replace their 2.0 installation with
the 2.0.1 release without any ill effects; apart from the license
change, we've only fixed bugs that didn't require us to make feature
changes.  The SRE package (regular expression matching, used by the
"re" module) was brought in line with the version distributed with
Python 2.1; this is stable feature-wise but much improved bug-wise.

For the full scoop, see the release notes on SourceForge:

    http://sourceforge.net/project/shownotes.php?release_id=40616

Python 2.1 users can ignore this release, unless they have an urgent
need for a GPL-compatible Python version and are willing to downgrade.
Rest assured that we're planning a bugfix release there too: I expect
that Python 2.1.1 will be released within a month, with the same
GPL-compatible license.  (Right, Thomas?)

We don't intend to build RPMs for 2.0.1.  If someone else is
interested in doing so, we can link to them.

--Guido van Rossum (home page: http://www.python.org/~guido/)


From tim.one@home.com  Sat Jun 23 10:17:54 2001
From: tim.one@home.com (Tim Peters)
Date: Sat, 23 Jun 2001 05:17:54 -0400
Subject: PEP 255: Simple Generators, Revised Posting
In-Reply-To: <BIEJKCLHCIOIHAGOKOLHOELICAAA.tim@digicool.com>
Message-ID: <mailman.993418261.10450.clpa-moderators@python.org>

Major revision:  more details about exceptions, return vs StopIteration, and
interactions with try/except/finally; more Q&A; and a BDFL Pronouncement.  The
reference implementation appears solid and works as described here in all
respects, so I expect this will be the last major revision (and so also last
full posting) of this PEP.

The output below is in ndiff format (see Tools/scripts/ndiff.py in your Python
distribution).  Just the new text can be seen in HTML form here:

    http://python.sf.net/peps/pep-0255.html

"Feature discussions" should take place primarily on the Python Iterators list:

    mailto:python-iterators@lists.sourceforge.net

Implementation discussions may wander in and out of Python-Dev too.


  PEP: 255
  Title: Simple Generators
- Version: $Revision: 1.3 $
?                       ^
+ Version: $Revision: 1.12 $
?                       ^^
  Author: nas@python.ca (Neil Schemenauer),
      tim.one@home.com (Tim Peters),
      magnus@hetland.org (Magnus Lie Hetland)
  Discussion-To: python-iterators@lists.sourceforge.net
  Status: Draft
  Type: Standards Track
  Requires: 234
  Created: 18-May-2001
  Python-Version: 2.2
- Post-History: 14-Jun-2001
+ Post-History: 14-Jun-2001, 23-Jun-2001
?                          +++++++++++++


  Abstract

      This PEP introduces the concept of generators to Python, as well
      as a new statement used in conjunction with them, the "yield"
      statement.


  Motivation

      When a producer function has a hard enough job that it requires
      maintaining state between values produced, most programming languages
      offer no pleasant and efficient solution beyond adding a callback
      function to the producer's argument list, to be called with each value
      produced.

      For example, tokenize.py in the standard library takes this approach:
      the caller must pass a "tokeneater" function to tokenize(), called
      whenever tokenize() finds the next token.  This allows tokenize to be
      coded in a natural way, but programs calling tokenize are typically
      convoluted by the need to remember between callbacks which token(s)
      were seen last.  The tokeneater function in tabnanny.py is a good
      example of that, maintaining a state machine in global variables, to
      remember across callbacks what it has already seen and what it hopes to
      see next.  This was difficult to get working correctly, and is still
      difficult for people to understand.  Unfortunately, that's typical of
      this approach.

      An alternative would have been for tokenize to produce an entire parse
      of the Python program at once, in a large list.  Then tokenize clients
      could be written in a natural way, using local variables and local
      control flow (such as loops and nested if statements) to keep track of
      their state.  But this isn't practical:  programs can be very large, so
      no a priori bound can be placed on the memory needed to materialize the
      whole parse; and some tokenize clients only want to see whether
      something specific appears early in the program (e.g., a future
      statement, or, as is done in IDLE, just the first indented statement),
      and then parsing the whole program first is a severe waste of time.

      Another alternative would be to make tokenize an iterator[1],
      delivering the next token whenever its .next() method is invoked.  This
      is pleasant for the caller in the same way a large list of results
      would be, but without the memory and "what if I want to get out early?"
      drawbacks.  However, this shifts the burden on tokenize to remember
      *its* state between .next() invocations, and the reader need only
      glance at tokenize.tokenize_loop() to realize what a horrid chore that
      would be.  Or picture a recursive algorithm for producing the nodes of
      a general tree structure:  to cast that into an iterator framework
      requires removing the recursion manually and maintaining the state of
      the traversal by hand.

      A fourth option is to run the producer and consumer in separate
      threads.  This allows both to maintain their states in natural ways,
      and so is pleasant for both.  Indeed, Demo/threads/Generator.py in the
      Python source distribution provides a usable synchronized-communication
      class for doing that in a general way.  This doesn't work on platforms
      without threads, though, and is very slow on platforms that do
      (compared to what is achievable without threads).

      A final option is to use the Stackless[2][3] variant implementation of
      Python instead, which supports lightweight coroutines.  This has much
      the same programmatic benefits as the thread option, but is much more
      efficient.  However, Stackless is a controversial rethinking of the
      Python core, and it may not be possible for Jython to implement the
      same semantics.  This PEP isn't the place to debate that, so suffice it
      to say here that generators provide a useful subset of Stackless
      functionality in a way that fits easily into the current CPython
      implementation, and is believed to be relatively straightforward for
      other Python implementations.

      That exhausts the current alternatives.  Some other high-level
      languages provide pleasant solutions, notably iterators in Sather[4],
      which were inspired by iterators in CLU; and generators in Icon[5], a
      novel language where every expression "is a generator".  There are
      differences among these, but the basic idea is the same:  provide a
      kind of function that can return an intermediate result ("the next
      value") to its caller, but maintaining the function's local state so
      that the function can be resumed again right where it left off.  A
      very simple example:

          def fib():
              a, b = 0, 1
              while 1:
                  yield b
                  a, b = b, a+b

      When fib() is first invoked, it sets a to 0 and b to 1, then yields b
      back to its caller.  The caller sees 1.  When fib is resumed, from its
      point of view the yield statement is really the same as, say, a print
      statement:  fib continues after the yield with all local state intact.
      a and b then become 1 and 1, and fib loops back to the yield, yielding
      1 to its invoker.  And so on.  From fib's point of view it's just
      delivering a sequence of results, as if via callback.  But from its
      caller's point of view, the fib invocation is an iterable object that
      can be resumed at will.  As in the thread approach, this allows both
      sides to be coded in the most natural ways; but unlike the thread
      approach, this can be done efficiently and on all platforms.  Indeed,
      resuming a generator should be no more expensive than a function call.

      The same kind of approach applies to many producer/consumer functions.
      For example, tokenize.py could yield the next token instead of invoking
      a callback function with it as argument, and tokenize clients could
      iterate over the tokens in a natural way:  a Python generator is a kind
      of Python iterator[1], but of an especially powerful kind.


- Specification
+ Specification:  Yield
?              ++++++++

      A new statement is introduced:

          yield_stmt:    "yield" expression_list

      "yield" is a new keyword, so a future statement[8] is needed to phase
-     this in.  [XXX spell this out]
+     this in.  [XXX spell this out -- but new keywords have ripple effects
+     across tools too, and it's not clear this can be forced into the future
+     framework at all -- it's not even clear that Python's parser alone can
+     be taught to swing both ways based on a future stmt]

      The yield statement may only be used inside functions.  A function that
-     contains a yield statement is called a generator function.
+     contains a yield statement is called a generator function.  A generator
?                                                               +++++++++++++
+     function is an ordinary function object in all respects, but has the
+     new CO_GENERATOR flag set in the code object's co_flags member.

      When a generator function is called, the actual arguments are bound to
      function-local formal argument names in the usual way, but no code in
      the body of the function is executed.  Instead a generator-iterator
      object is returned; this conforms to the iterator protocol[6], so in
      particular can be used in for-loops in a natural way.  Note that when
      the intent is clear from context, the unqualified name "generator" may
      be used to refer either to a generator-function or a generator-
      iterator.

      Each time the .next() method of a generator-iterator is invoked, the
      code in the body of the generator-function is executed until a yield
      or return statement (see below) is encountered, or until the end of
      the body is reached.

      If a yield statement is encountered, the state of the function is
      frozen, and the value of expression_list is returned to .next()'s
      caller.  By "frozen" we mean that all local state is retained,
      including the current bindings of local variables, the instruction
      pointer, and the internal evaluation stack:  enough information is
      saved so that the next time .next() is invoked, the function can
      proceed exactly as if the yield statement were just another external
      call.

+     Restriction:  A yield statement is not allowed in the try clause of a
+     try/finally construct.  The difficulty is that there's no guarantee
+     the generator will ever be resumed, hence no guarantee that the finally
+     block will ever get executed; that's too much a violation of finally's
+     purpose to bear.
+
+
+ Specification:  Return
+
      A generator function can also contain return statements of the form:

          "return"

      Note that an expression_list is not allowed on return statements
      in the body of a generator (although, of course, they may appear in
      the bodies of non-generator functions nested within the generator).

-     When a return statement is encountered, nothing is returned, but a
+     When a return statement is encountered, control proceeds as in any
+     function return, executing the appropriate finally clauses (if any
-     StopIteration exception is raised, signalling that the iterator is
?                                                           ------------
+     exist).  Then a StopIteration exception is raised, signalling that the
?    ++++++++++++++++
-     exhausted.   The same is true if control flows off the end of the
+     iterator is exhausted.   A StopIteration exception is also raised if
+     control flows off the end of the generator without an explict return.
+
-     function.  Note that return means "I'm done, and have nothing
?   -----------
+     Note that return means "I'm done, and have nothing interesting to
?                                                       +++++++++++++++
-     interesting to return", for both generator functions and non-generator
?    ---------------
+     return", for both generator functions and non-generator functions.
?                                                            +++++++++++
-     functions.
+
+     Note that return isn't always equivalent to raising StopIteration:  the
+     difference lies in how enclosing try/except constructs are treated.
+     For example,
+
+         >>> def f1():
+         ...     try:
+         ...         return
+         ...     except:
+         ...        yield 1
+         >>> print list(f1())
+         []
+
+     because, as in any function, return simply exits, but
+
+         >>> def f2():
+         ...     try:
+         ...         raise StopIteration
+         ...     except:
+         ...         yield 42
+         >>> print list(f2())
+         [42]
+
+     because StopIteration is captured by a bare "except", as is any
+     exception.
+
+
+ Specification:  Generators and Exception Propagation
+
+     If an unhandled exception-- including, but not limited to,
+     StopIteration --is raised by, or passes through, a generator function,
+     then the exception is passed on to the caller in the usual way, and
+     subsequent attempts to resume the generator function raise
+     StopIteration.  In other words, an unhandled exception terminates a
+     generator's useful life.
+
+     Example (not idiomatic but to illustrate the point):
+
+     >>> def f():
+     ...     return 1/0
+     >>> def g():
+     ...     yield f()  # the zero division exception propagates
+     ...     yield 42   # and we'll never get here
+     >>> k = g()
+     >>> k.next()
+     Traceback (most recent call last):
+       File "<stdin>", line 1, in ?
+       File "<stdin>", line 2, in g
+       File "<stdin>", line 2, in f
+     ZeroDivisionError: integer division or modulo by zero
+     >>> k.next()  # and the generator cannot be resumed
+     Traceback (most recent call last):
+       File "<stdin>", line 1, in ?
+     StopIteration
+     >>>
+
+
+ Specification:  Try/Except/Finally
+
+     As noted earlier, yield is not allowed in the try clause of a try/
+     finally construct.  A consequence is that generators should allocate
+     critical resources with great care.  There is no restriction on yield
+     otherwise appearing in finally clauses, except clauses, or in the try
+     clause of a try/except construct:
+
+     >>> def f():
+     ...     try:
+     ...         yield 1
+     ...         try:
+     ...             yield 2
+     ...             1/0
+     ...             yield 3  # never get here
+     ...         except ZeroDivisionError:
+     ...             yield 4
+     ...             yield 5
+     ...             raise
+     ...         except:
+     ...             yield 6
+     ...         yield 7     # the "raise" above stops this
+     ...     except:
+     ...         yield 8
+     ...     yield 9
+     ...     try:
+     ...         x = 12
+     ...     finally:
+     ...         yield 10
+     ...     yield 11
+     >>> print list(f())
+     [1, 2, 4, 5, 8, 9, 10, 11]
+     >>>


  Example

          # A binary tree class.
          class Tree:

              def __init__(self, label, left=None, right=None):
                  self.label = label
                  self.left = left
                  self.right = right

              def __repr__(self, level=0, indent="    "):
                  s = level*indent + `self.label`
                  if self.left:
                      s = s + "\n" + self.left.__repr__(level+1, indent)
                  if self.right:
                      s = s + "\n" + self.right.__repr__(level+1, indent)
                  return s

              def __iter__(self):
                  return inorder(self)

          # Create a Tree from a list.
          def tree(list):
              n = len(list)
              if n == 0:
                  return []
              i = n / 2
              return Tree(list[i], tree(list[:i]), tree(list[i+1:]))

          # A recursive generator that generates Tree leaves in in-order.
          def inorder(t):
              if t:
                  for x in inorder(t.left):
                      yield x
                  yield t.label
                  for x in inorder(t.right):
                      yield x

          # Show it off: create a tree.
          t = tree("ABCDEFGHIJKLMNOPQRSTUVWXYZ")
          # Print the nodes of the tree in in-order.
          for x in t:
              print x,
          print

          # A non-recursive generator.
          def inorder(node):
              stack = []
              while node:
                  while node.left:
                      stack.append(node)
                      node = node.left
                  yield node.label
                  while not node.right:
                      try:
                          node = stack.pop()
                      except IndexError:
                          return
                      yield node.label
                  node = node.right

          # Exercise the non-recursive generator.
          for x in t:
              print x,
          print

+     Both output blocks display:
+
+         A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
+

  Q & A

+     Q. Why not a new keyword instead of reusing "def"?
+
+     A. See BDFL Pronouncements section below.
+
-     Q. Why a new keyword?  Why not a builtin function instead?
+     Q. Why a new keyword for "yield"?  Why not a builtin function instead?
?                         ++++++++++++

      A. Control flow is much better expressed via keyword in Python, and
         yield is a control construct.  It's also believed that efficient
         implementation in Jython requires that the compiler be able to
         determine potential suspension points at compile-time, and a new
-        keyword makes that easy.
+        keyword makes that easy.  The CPython referrence implementation also
+        exploits it heavily, to detect which functions *are* generator-
+        functions (although a new keyword in place of "def" would solve that
+        for CPython -- but people asking the "why a new keyword?" question
+        don't want any new keyword).
+
+     Q: Then why not some other special syntax without a new keyword?  For
+        example, one of these instead of "yield 3":
+
+        return 3 and continue
+        return and continue 3
+        return generating 3
+        continue return 3
+        return >> , 3
+        from generator return 3
+        return >> 3
+        return << 3
+        >> 3
+        << 3
+
+     A: Did I miss one <wink>?  Out of hundreds of messages, I counted two
+        suggesting such an alternative, and extracted the above from them.
+        It would be nice not to need a new keyword, but nicer to make yield
+        very clear -- I don't want to have to *deduce* that a yield is
+        occurring from making sense of a previously senseless sequence of
+        keywords or operators.  Still, if this attracts enough interest,
+        proponents should settle on a single consensus suggestion, and Guido
+        will Pronounce on it.
+
+     Q. Why allow "return" at all?  Why not force termination to be spelled
+        "raise StopIteration"?
+
+     A. The mechanics of StopIteration are low-level details, much like the
+        mechanics of IndexError in Python 2.1:  the implementation needs to
+        do *something* well-defined under the covers, and Python exposes
+        these mechanisms for advanced users.  That's not an argument for
+        forcing everyone to work at that level, though.  "return" means "I'm
+        done" in any kind of function, and that's easy to explain and to use.
+        Note that "return" isn't always equivalent to "raise StopIteration"
+        in try/except construct, either (see the "Specification: Return"
+        section).
+
+     Q. Then why not allow an expression on "return" too?
+
+     A. Perhaps we will someday.  In Icon, "return expr" means both "I'm
+        done", and "but I have one final useful value to return too, and
+        this is it".  At the start, and in the absence of compelling uses
+        for "return expr", it's simply cleaner to use "yield" exclusively
+        for delivering values.
+
+
+ BDFL Pronouncements
+
+     Issue:  Introduce another new keyword (say, "gen" or "generator") in
+     place of "def", or otherwise alter the syntax, to distinguish
+     generator-functions from non-generator functions.
+
+     Con:  In practice (how you think about them), generators *are*
+     functions, but with the twist that they're resumable.  The mechanics of
+     how they're set up is a comparatively minor technical issue, and
+     introducing a new keyword would unhelpfully overemphasize the
+     mechanics of how generators get started (a vital but tiny part of a
+     generator's life).
+
+     Pro:  In reality (how you think about them), generator-functions are
+     actually factory functions that produce generator-iterators as if by
+     magic.  In this respect they're radically different from non-generator
+     functions, acting more like a constructor than a function, so reusing
+     "def" is at best confusing.  A "yield" statement buried in the body is
+     not enough warning that the semantics are so different.
+
+     BDFL:  "def" it stays.  No argument on either side is totally
+     convincing, so I have consulted my language designer's intuition.  It
+     tells me that the syntax proposed in the PEP is exactly right - not too
+     hot, not too cold.  But, like the Oracle at Delphi in Greek mythology,
+     it doesn't tell me why, so I don't have a rebuttal for the arguments
+     against the PEP syntax.  The best I can come up with (apart from
+     agreeing with the rebuttals ... already made) is "FUD".  If this had
+     been part of the language from day one, I very much doubt it would have
+     made Andrew Kuchling's "Python Warts" page.


  Reference Implementation

-     A preliminary patch against the CVS Python source is available[7].
+     The current implementation, in a preliminary state (no docs and no
+     focused tests), is part of Python's CVS development tree[9].
+     Using this requires that you build Python from source.
+
+     This was derived from an earlier patch by Neil Schemenauer[7].


  Footnotes and References

      [1] PEP 234, http://python.sf.net/peps/pep-0234.html
      [2] http://www.stackless.com/
      [3] PEP 219, http://python.sf.net/peps/pep-0219.html
      [4] "Iteration Abstraction in Sather"
          Murer , Omohundro, Stoutamire and Szyperski
          http://www.icsi.berkeley.edu/~sather/Publications/toplas.html
      [5] http://www.cs.arizona.edu/icon/
      [6] The concept of iterators is described in PEP 234
          http://python.sf.net/peps/pep-0234.html
      [7] http://python.ca/nas/python/generator.diff
      [8] http://python.sf.net/peps/pep-0236.html
+     [9] To experiment with this implementation, check out Python from CVS
+         according to the instructions at
+             http://sf.net/cvs/?group_id=5470


  Copyright

      This document has been placed in the public domain.


  
  Local Variables:
  mode: indented-text
  indent-tabs-mode: nil
  End:



From michael@stroeder.com  Sat Jun 23 23:29:00 2001
From: michael@stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 24 Jun 2001 00:29:00 +0200
Subject: ANNOUNCE: web2ldap 0.9.4
Message-ID: <mailman.993418261.10451.clpa-moderators@python.org>

HI!

Find a new release of web2ldap on:

  http://www.web2ldap.de/download.html

web2ldap is a web-based generic LDAP client written in Python.

Ciao, Michael.

web2ldap 0.9.4

 Release Date: 2001-06-23
 
 Changes since 0.9.3:
   * Fixed displaying of iPAddress attribute in certificates.
   * Abandoned global configuration parameter
     web2ldapcnf.misc.script_method.
   * Slightly improved excpetion handling especially of
     logging/ignoring user-aborted connections, etc.
   * Determining appropriate charset used with browser was improved:
     mainly proper parsing of capability values.
   * A lookup of SRV RRs is automatically done if a LDAP URL does
not
     contain a host name but a "dc-style" DN (a DN formed by
     domainComponent attributes).
   * New configuration sub-module fastcgi.
   * Some really significant performance optimizations in
ldapthreading
     module. Former approach in method LDAPObject.result() was
     brain-dead and slow.
   * Web session ID is now passed around in PATH_INFO instead as a
     hidden form field. This means less HTML bloat and it decoupled
     session retrieving from form processing.
   * If ldap.NAMING_VIOLATION occurs during add the user can reedit
his
     input.
   * Fixed smart login search with user names containing NON-ASCII
     chars. (sigh!)
   * Fixed wrong passing of parameters when calling function
     ldapbase.SmartLogin().
   * Use timeout search for smart login.


From gritsch@iue.tuwien.ac.at  Sun Jun 24 11:32:21 2001
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Sun, 24 Jun 2001 12:32:21 +0200
Subject: [ANN] VideoCapture 0.2 released
Message-ID: <mailman.993418261.10452.clpa-moderators@python.org>

VideoCapture-0.2
================

URL:
----
http://stud4.tuwien.ac.at/~e9326522/VideoCapture/

What it is:
-----------
VideoCapture is a Python extension for Win32 which makes it possible
to access video-capture devices (e.g. a USB webcam).

What is new in version 0.2:
---------------------------
*) Added extensive error checking after every system call.  In case
   something goes wrong an exception is raised.
*) Some enhancements to the high level interface like selectable
   fontstyle, various shadow modes for better font legibility.
*) The video-device that should be used can be specified.

Contact:
--------
Markus Gritsch (gritsch@iue.tuwien.ac.at)


Enjoy and have fun!





From michael@stroeder.com  Mon Jun 25 17:55:33 2001
From: michael@stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Mon, 25 Jun 2001 18:55:33 +0200
Subject: msWeb 1.0.0
Message-ID: <mailman.993565741.7736.clpa-moderators@python.org>

HI!

I'd like to announce msWeb which is yet another module package for
web programming with Python (formerly probably not known ;-) as a
bunch of separate modules cgiforms, cgisession etc.).

You can find it on:

  http://www.stroeder.com/msWeb/

But be warned that documentation is very sparse (some short examples
and pydoc-generated HTML).

Ciao, Michael.


From djc@object-craft.com.au  Tue Jun 26 11:33:45 2001
From: djc@object-craft.com.au (Dave Cole)
Date: 26 Jun 2001 20:33:45 +1000
Subject: Sybase module 0.27 released
Message-ID: <mailman.993565741.7738.clpa-moderators@python.org>

What is it:

The Sybase module provides a Python interface to the Sybase relational
database system. The Sybase package supports almost all of the Python
Database API, version 2.0 with extensions.

The module works with Python versions 1.5.2 and later and Sybase
versions 11.0.3 and later.  It is based on the Sybase Client Library
(ct_* API), and the Bulk-Library Client (blk_* API) interfaces.

The 0.20 and later releases are a re-implementation of the module using
a thin C wrapper on the Sybase-CT API, and a Python module to provide
the DB-API functionality.  It is still a work in progress, but should
be good enough for most purposes.

Changes for this release:

- Sybase.py module no longer imports exceptions module.

- Optional auto_commit argument has been added to Sybase.connect().
  The default value is 0.

- Optional delay_connect argument has been added to Sybase.connect().
  The default value is 0.  This allows you to manipulate the Sybase
  connection before connecting to the server.

>>> import Sybase
>>> db = Sybase.connect(server, user, passwd, delay_connect = 1)
>>> db.set_property(Sybase.CS_HOSTNAME, 'secret')
>>> db.connect()

- Removed redundant argument from sybasect.ct_data_info()

- Added pickle capability to NumericType - I somehow forgot to copy
  this over from the old 0.13 module.

- Re-arranged sybasect.h to make it easier to follow - I hope.

- Documentation updates.

- Dave

-- 
http://www.object-craft.com.au



From guido@digicool.com  Tue Jun 26 18:59:55 2001
From: guido@digicool.com (Guido van Rossum)
Date: Tue, 26 Jun 2001 13:59:55 -0400
Subject: PEP 260: simplify xrange()
Message-ID: <mailman.993644340.10286.clpa-moderators@python.org>

Here's another sweet and short PEP.  What do folks think?  Is
xrange()'s complexity really worth having?

--Guido van Rossum (home page: http://www.python.org/~guido/)

PEP: 260
Title: Simplify xrange()
Version: $Revision: 1.1 $
Author: guido@python.org (Guido van Rossum)
Status: Draft
Type: Standards Track
Python-Version: 2.2
Created: 26-Jun-2001
Post-History: 26-Jun-2001

Abstract

    This PEP proposes to strip the xrange() object from some rarely
    used behavior like x[i:j] and x*n.


Problem

    The xrange() function has one idiomatic use:

        for i in xrange(...): ...

    However, the xrange() object has a bunch of rarely used behaviors
    that attempt to make it more sequence-like.  These are so rarely
    used that historically they have has serious bugs (e.g. off-by-one
    errors) that went undetected for several releases.

    I claim that it's better to drop these unused features.  This will
    simplify the implementation, testing, and documentation, and
    reduce maintenance and code size.


Proposed Solution

    I propose to strip the xrange() object to the bare minimum.  The
    only retained sequence behaviors are x[i], len(x), and repr(x).
    In particular, these behaviors will be dropped:

        x[i:j] (slicing)
        x*n, n*x (sequence-repeat)
        cmp(x1, x2) (comparisons)
	i in x (containment test)
        x.tolist() method
        x.start, x.stop, x.step attributes

    By implementing a custom iterator type, we could speed up the
    common use, but this is optional (the default sequence iterator
    does just fine).

    I expect it will take at most an hour to rip it all out; another
    hour to reduce the test suite and documentation.


Scope

    This PEP only affects the xrange() built-in function.


Risks

    Somebody's code could be relying on the extended code, and this
    code would break.  However, given that historically bugs in the
    extended code have gone undetected for so long, it's unlikely that
    much code is affected.


Copyright

    This document has been placed in the public domain.


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:


From djc@object-craft.com.au  Wed Jun 27 04:05:27 2001
From: djc@object-craft.com.au (Dave Cole)
Date: 27 Jun 2001 13:05:27 +1000
Subject: Sybase module 0.28 (Brown Paper Bag) released
Message-ID: <mailman.993644341.10291.clpa-moderators@python.org>

What is it:

The Sybase module provides a Python interface to the Sybase relational
database system. The Sybase package supports almost all of the Python
Database API, version 2.0 with extensions.

The module works with Python versions 1.5.2 and later and Sybase
versions 11.0.3 and later.  It is based on the Sybase Client Library
(ct_* API), and the Bulk-Library Client (blk_* API) interfaces.

The 0.20 and later releases are a re-implementation of the module using
a thin C wrapper on the Sybase-CT API, and a Python module to provide
the DB-API functionality.  It is still a work in progress, but should
be good enough for most purposes.

Changes for this release:

After shooting my mouth off about the cool things that you can do with
bulkcopy I went back and tested my claims.  I found that I had not
implemented support for the bulkcopy optional argument to
Sybase.connect()...

Changes for this release:

- The following claim I made earlier today on comp.lang.python is now
  true:

  If your source data is CSV format then you can use another one of the
  modules I wrote to load it into a format suitable to feeding the
  bulkcopy object in the Sybase module.  The module was written
  specifically to handle data type data produced by Access and Excel.
  
          http://www.object-craft.com.au/projects/csv/
  
  >>> import Sybase, csv
  >>>
  >>> db = Sybase.connect('SYBASE', 'user', 'password', bulkcopy = 1, auto_commit = 1)
  >>> db.execute('create table #bogus (name varchar(40), num int)')
  >>> 
  >>> p = csv.parser()
  >>> bcp = db.bulkcopy('#bogus')
  >>> for line in open('datafile').readlines():
  >>>     fields = p.parse(line)
  >>>     if fields:
  >>>         bcp.rowxfer(line)
  >>> print 'Loaded', bcp.done(), 'rows'

- Documentation updates.

- Dave

P.S.  Hopefully there will be a period of more than one day before the
      next release...

-- 
http://www.object-craft.com.au



From PyChecker <pychecker@metaslash.com>  Wed Jun 27 12:48:00 2001
From: PyChecker <pychecker@metaslash.com> (Neal Norwitz)
Date: Wed, 27 Jun 2001 07:48:00 -0400
Subject: ANN: PyChecker version 0.6.1
Message-ID: <mailman.993644341.10292.clpa-moderators@python.org>

A new version of PyChecker is available for your hacking pleasure.

	PyChecker is a tool for finding common bugs in python source code.
	It finds problems that are typically caught by a compiler for less
	dynamic languages, like C and C++.

Comments, criticisms, new ideas, and other feedback is welcome.

Here's the CHANGELOG:
  * Check format strings: "%s %s %s" % (v1, v2, v3, v4) for arg counts
  * Warn when format strings do: '%(var) %(var2)'
  * Fix Local variable (xxx) not used, when have:  "%(xxx)s" % locals()
  * Warn when local variable (xxx) doesn't exist and have: "%(xxx)s" % locals()
  * Install script in /usr/local/bin to invoke PyChecker
  * Don't produce unused global warnings when using a module in parameters
  * Don't produce unused global warnings when using a module in class variables
  * Add check when using method as an attribute (if self.method and x == y:)
  * Add check for right # of args to object construction
  * Add check for right # of args to function calls in other modules
  * Check for returning a value from __init__
  * Fix using from XX import YY ; from XX import ZZ causing re-import warning
  * Fix UNABLE TO IMPORT errors for files that don't end with a newline
  * Support for checking consistent return values -- not complete
        produces too many false positives 
	(off by default, use -r/--returnvalues to enable)

PyChecker is available on Source Forge:
    Web page:           http://pychecker.sourceforge.net/
    Project page:       http://sourceforge.net/projects/pychecker/

Neal
--
pychecker@metaslash.com


From danbarthel@se.mediaone.net  Wed Jun 27 16:50:57 2001
From: danbarthel@se.mediaone.net (Dan Barthel)
Date: Wed, 27 Jun 2001 11:50:57 -0400
Subject: Authors needed for Python Books
Message-ID: <mailman.993657901.31758.clpa-moderators@python.org>

Hi,

I'm looking for Python authors in several areas. Guido suggested I post
my request.

1. Introduction to Programming. An introductory book, ideally by an
educator, to teach Python as a first language. Not for CS people, but
for mortals.
2. Web Programming with Python. Using Python as a CGI scripting
language.
3. XML Programming with Python. All the usual XML stuff, plus SOAP.
4. Expert Zope. Making the most of Zope.
5. If you have a topic you would like to publish, I'll listen.

If anyone has a desire to jump in on any of the above topics, please let
me know. We would like to expand our selection of excellent Python books
at Manning.

Regards,

Dan

=======================================
Dan Barthel
Acquisitions Editor
Manning Publications Co.
32 Lafayette Place, Greenwich, CT 06830
941-394-6662   www.manning.com
=======================================



From Cayce@actzero.com  Thu Jun 28 01:37:09 2001
From: Cayce@actzero.com (Cayce Ullman)
Date: Wed, 27 Jun 2001 17:37:09 -0700
Subject: ANN: SOAP.py 0.9.7
Message-ID: <mailman.993726240.19493.clpa-moderators@python.org>

The latest version of SOAP.py (a SOAP implementation in written in Python),
was released today.  
We're moving the project from actzero to sourceforge.  It now can be found
at :

http://sourceforge.net/projects/pywebsvcs/

Comments, feedback, patches, etc... very welcome.

Changes since last announcement:

VERSION 0.9.7 (6/27/01)
- Fixed the un-named ordered parameters bug
- Added the ability to specify a http_proxy
- Added a patch provided by Tim MiddelKoop to allow printing of proxy
objects
- Added the contrib directory and included a medusa implementation of a 
  SOAP.py server by Ng Pheng Siong


VERSION 0.9.6 (6/08/01)

- The date and time types now check their initial values when the type
  is created, not when the data is marshalled.
- The date and time types are now parsed and returned as tuples (for
  multi-element types) or scalars (for single element types) in UTC and thus
  can represent the entire range of SOAP dates.
- If an element doesn't have a type but has a name with a namespace, the
  name is tried as the type.
- Untyped compound types with more than one element and all the elements
  the same name are turned into an array when parsing.
- When parsing a structType, elements with the same name are placed in a
  list instead of saving just the last one. _getItemsAsList can be used to
  get an element of a structure as a list, whether there was one or many
  occurances of the item.
- Added schemaNamespace, schemaNamespaceURI, and namespaceStyle
  configuration options. namespaceStyle takes one of 1999, 2000, or 2001,
  and sets typesNamespace, typesNamespaceURI, schemaNamespace, and
  schemaNamespaceURI.
- Normalized the type class names, replacing Compound with compoundType,
  Struct with structType, Header with headerType, Body with bodyType, Array
  with arrayType, TypedArray with typedArrayType, Fault with faultType, and
  urType with anyType.
- Attributes now appear on an element itself instead of the element's
  parent. For elements parsed to builtin python types, the attributes are
  stored in a dictionary keyed by the element's python id. The dictionary
  is in the Context object, can be returned from parseSOAP*, and can be
  returned from method calls if the returnAllAttrs configuration option
  is set.
- isinstance is used to check for a class, so classes can be subtyped.
- An encoding of None can be specified to not include encoding information.
- Problems with the SOAPProxy URL are now reported when the SOAPProxy
  instance is created instead of when the first method call is made.
- The Binary, Boolean and DateTime types have been removed in favor of
  binaryType, booleanType, and dateTimeType.



From gritsch@iue.tuwien.ac.at  Thu Jun 28 17:09:00 2001
From: gritsch@iue.tuwien.ac.at (Markus Gritsch)
Date: Thu, 28 Jun 2001 18:09:00 +0200
Subject: ANN: VideoCapture 0.3 released
Message-ID: <mailman.993819900.30646.clpa-moderators@python.org>

VideoCapture-0.3
================

URL:
----
http://stud4.tuwien.ac.at/~e9326522/VideoCapture/

What it is:
-----------
VideoCapture is a Python extension for Win32 which makes it possible
to access video-capture devices (e.g. a USB webcam).

What is new in version 0.3:
---------------------------
*) Included a precompiled binary of the low level module linked
   against Pyhton 2.1 (in addition to the one which was already there
   for Python 2.0).
*) Added a tool to periodically upload a WebCam-image to a WebServer
   via FTP.
*) Added a tool to monitor (and save in case of a change) a Picture
   located at a given URL.
*) More than one Device instance can be held open at the same time.
*) The location of the timestamp in the image is selectable.

ATTENTION:
----------
I would like to put a list of Python-powered WebCam URLs together, so
please send me an email with the URL of the image or HTML page if you
use VideoCapture.

Contact:
--------
Markus Gritsch (gritsch@iue.tuwien.ac.at)


Enjoy and have fun!




From fdrake@acm.org  Fri Jun 29 20:24:00 2001
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 29 Jun 2001 15:24:00 -0400 (EDT)
Subject: Python 2.1 docs in GNU info format
Message-ID: <mailman.993935581.14889.clpa-moderators@python.org>

  Milan Zamazal has contributed Python 2.1 documentation in GNU info
format.  It is available on python.org:

ftp://ftp.python.org/pub/python/doc/2.1/

and on SourceForge:

http://sourceforge.net/project/showfiles.php?group_id=5470&release_id=41415

  Thanks, Milan!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations



From michael@stroeder.com  Sat Jun 30 23:04:37 2001
From: michael@stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 01 Jul 2001 00:04:37 +0200
Subject: PyWebLib 1.0.1
Message-ID: <mailman.994112170.2372.clpa-moderators@python.org>

HI!

I'd like to announce PyWebLib (formerly announced as msweb). I
renamed it to avoid a name clash with a commercial product.

You can find it on:

  http://www.stroeder.com/pylib/PyWebLib/

But be warned that documentation is very sparse (some short examples
and pydoc-generated HTML).

Ciao, Michael.