From clifford.wells@attbi.com  Fri Nov  1 02:10:14 2002
From: clifford.wells@attbi.com (Cliff Wells)
Date: 31 Oct 2002 18:10:14 -0800
Subject: Python-DSV 1.3.6
Message-ID: <mailman.1036157172.11788.clpa-moderators@python.org>

Version 1.3.6 of Python-DSV is available 

http://python-dsv.sourceforge.net/

This is mostly a bugfix release.  Several um, unique arrangements of CSV
data are now handled (hopefully) gracefully.  This involved replacing a
central portion of DSV.py, so bug reports are welcome.

What is it?
Python-DSV is a Python module that imports and exports CSV files.  It is
unique in that it has heuristics for determining the format of the file
being imported.  It also has an optional wxPython dialog for user
interaction.  It is pure Python so it should be very portable.

Regards,
Cliff



From salmonia.nospam.please@cardiff.ac.uk  Tue Nov  5 17:18:22 2002
From: salmonia.nospam.please@cardiff.ac.uk (Alan James Salmoni)
Date: Tue, 05 Nov 2002 17:18:22 +0000
Subject: ANN: New release of SalStat Statistics Package
Message-ID: <mailman.1036518125.14633.clpa-moderators@python.org>

Here is a new release of the SalStat statistics package, written in 
Python and wxPython (codenamed "Pugh").

This release contains a large number of improvements, among them: 
Windows and Linux self-contained files (binaries with no dependencies - 
the McMillan installer really works well!) and a self-extracting 
installer for Windows; New tests; Interface cleanup; Scripting support 
(access your data using Python and write your own tests!); Extremely 
basic bar charts for the means (the Windows version doesn't seem to work 
as well as the Linux one); Saving and printing of analysis output; a new 
manual (pdf, text and TeX format); A general usability improvement.

There are lots of things to look at, so please send comments and bug 
reports to the author (see the website for more details).

Alan James Salmoni
SalStat Developer.



From Jack.Jansen@oratrix.com  Fri Nov  1 23:17:57 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sat, 2 Nov 2002 00:17:57 +0100
Subject: MacPython 2.2.2 is available
Message-ID: <mailman.1036692961.24655.clpa-moderators@python.org>

MacPython 2.2.2 is available via 
<http://www.cwi.nl/~jack/macpython.html>.

This release should be fully backward compatible to 2.2.1 (and 
2.2). Aside from the 120 or so machine-independent bug fixes 
there are two important Mac-specific fixes:
- MacPython now installs and runs on Jaguar (Mac OS X 10.2)
- the occasional refusal of Python to run (showing only a 
<<terminated>> window) has been fixed.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -



From carlca@dircon.co.uk  Tue Nov  5 21:47:39 2002
From: carlca@dircon.co.uk (Carl Caulkett)
Date: Tue, 05 Nov 2002 21:47:39 +0000
Subject: ANN: New release of SalStat Statistics Package
References: <mailman.1036518125.14633.clpa-moderators@python.org>
Message-ID: <mailman.1036692962.24656.clpa-moderators@python.org>

On Tue, 05 Nov 2002 17:18:22 +0000, Alan James Salmoni
<salmonia.nospam.please@cardiff.ac.uk> wrote:

> (see the website for more details).

Ahem...

http://salstat.sunsite.dk/

<g>

-- 
Carl


From kiko@async.com.br  Tue Nov  5 23:20:50 2002
From: kiko@async.com.br (Christian Reis)
Date: Tue, 5 Nov 2002 21:20:50 -0200
Subject: ANNOUNCE: Kiwi 0.5.0
Message-ID: <mailman.1036692962.24657.clpa-moderators@python.org>

I'm releasing today version 0.5.0 of Kiwi, a framework for developing
graphical applications using Python and based on PyGTK. This is the
sixth public release of Kiwi, and in this version it has evolved into a
quite complete application framework, with many perks and niceties. Grab
the latest code from:
    
    http://www.async.com.br/projects/kiwi/

If you are looking for something to make Python applications using GTK
*much* easier to code, more Python-like, and with extended widget
functionality, try Kiwi. This release adds a complete development guide
and API documentation (generated with Edward Loper's excellent epydoc
tool), the guide itself providing a lot of information on Kiwi
development:

    http://www.async.com.br/projects/kiwi/howto/

Kiwi is used in Stoq (www.stoq.com.br), a GPLed retail system that is
based on Python and PyGTK, and for internal development at SecurePipe,
Inc. (www.securepipe.com).

Kiwi is free software licensed through the GNU LGPL.

Features include:

- MVC-like base classes to structure an application into logical
  modules, including a Visual Proxy, Delegates and traditional Views and
  Controllers.
- Full, transparent support for libglade, allowing UI development to be done
  graphically, and keeping implementation inside your instance of the
  framework.
- Automatic signal connection based on function names; no need to
  connect() manually or use Glade's signal interface
- Enhanced CList, CTree, OptionMenu, Label and Combo classes based on
  the related PyGTK widgets.
- A complete development guide, and complete API documentation. 
- Examples and tests, and lots of code.

This update provides:

- Complete API documentation and a detailed guide full of examples and
  screenshots. 
- Proxy and Model classes, that provide a way to attach an instance to
  an interface and have it be instantly updated without requiring any
  extra coding. This is a very special feature that apps *much* easier
  to code.
- CListDelegate, a configurable CList that provides a very high-level
  API for listing instances and configuring the CList width, visibility,
  alignment, tooltips and more.
- We now have Delegate classes (combined Views and Controllers) that
  provide even more simplified ways to create interfaces.
- The Kiwi license has been changed to LGPL in preparation for the first
  major release.
- Serious optimizations to CList reordering.
- Lots of code cleanup and refactoring.
- Docstrings for all public methods and classes. 
- Over 15 example programs and 17 different tests.
- Meaningless statistics:
    Diff changes: +16049/-11521; Checkins: 522; LOC: 4520(raw), 2429(sloc)
    11 modules, 31 classes, 278 methods

Many thanks to Jon Nelson, Ricardo Froehlich and Johan Dahlin for
helping out with this version; lots of regression testing, suggestions
and code examples were contributed by them.

Kiwi Homepage:
    http://www.async.com.br/projects/kiwi/

Online documentation:
    HOWTO: http://www.async.com.br/projects/kiwi/howto/
    API reference: http://www.async.com.br/projects/kiwi/api/

Download Kiwi 0.5.0 from
    http://www.async.com.br/projects/kiwi/dl/Kiwi-0.5.0.tar.gz

We have Bonsai and Bugzilla available for Kiwi:
    http://bonsai.async.com.br/ 
    http://bugs.async.com.br/

Feedback can come directly to me, kiko@async.com.br, or through the
PyGTK list, pygtk@daa.com.au

If you are using Kiwi in your project, it would be really nice to drop
me a line and let me know, I would like to add a list to the homepage
but I don't know most of you :)

I know I promised this the last time, but development focus shifted to
the framework and documentation; this means there is still no validated
Entry. The next major release will include a reworked Entry widget that
offers right-alignment (contributed by Johan) and validation.  This work
has progressed nicely but is still not quite ready, so I chose to leave
it out for now.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL


From rjones@ekit-inc.com  Wed Nov  6 11:58:35 2002
From: rjones@ekit-inc.com (Richard Jones)
Date: Wed, 6 Nov 2002 22:58:35 +1100
Subject: SC-Track Roundup 0.5.2 - an issue tracking system
Message-ID: <mailman.1036692962.24658.clpa-moderators@python.org>

=================================================
SC-Track Roundup 0.5.2 - an issue tracking system
=================================================

This is a bugfix release for version 0.5.x - if you're upgrading from before
that, you *must* read doc/upgrading.txt!

Unfortunately, the Zope frontend for Roundup is currently broken, with no
fix in the forseeable future.

Roundup requires python 2.1.3 or later for correct operation. Users of the
sqlite backend are encouraged to upgrade sqlite to version 2.7.3.

We've had a good crack at bugs (thanks to all who contributed!):

- added quotes around python interpreter in windows bat (sf bug 623963)
- fixed link at end of installation doc (sf bug 623957)
- handle "classname" URL path errors cleaner (generate a 404)
- added CGI :remove:<propname> and :add:<propname> which specify item
  ids to remove / add in <propname> multilink.
- bugfix in boolean templating
- remember the change note on bad submissions (sf bug 625989)
- highlight required form fields (sf bug 625989)
- force non-word boundary to match re: in subject (sf bug 626303)
- handle sqlite bug (<2.7.2) (sf bug 630828)
- handle missing props in anydbm stringFind
- updated email package address formatting (deprecation)
- copied email address quoting from email v2.4.3 so we're consistent
  with 2.2
- email summary extraction now takes the first whole sentence or line -
  whichever is longer
- documented dependency on Active State (sf bug 623959)
- ensured there's no zero-length files in source (sf bug 633622)
- added ID to the search page (sf bug 631601)
- fixed filtering by id in anydbm
- show issue ID in the headings (sf bug 631598)
- show entire messages by default in issues (sf bug 625995)
- fixed journalling to save old values instead of new (sorry I took so
  long, GM)
- handle missing REQUEST_URI for cgi-bin users (sf bug 620163)


Source and documentation is available at the website:
     http://roundup.sourceforge.net/
Release Info (via download page):
     http://sourceforge.net/projects/roundup
Mailing lists - the place to ask questions:
     http://sourceforge.net/mail/?group_id=31577


About Roundup
=============

Roundup is a simple-to-use and -install issue-tracking system with 
command-line, web and e-mail interfaces. It is based on the winning design 
from Ka-Ping Yee in the Software Carpentry "Track" design competition.

Note: Ping is not responsible for this project. The contact for this project 
is richard@users.sourceforge.net.

Roundup manages a number of issues (with flexible properties such as 
"description", "priority", and so on) and provides the ability to:

(a) submit new issues,
(b) find and edit existing issues, and
(c) discuss issues with other participants.

The system will facilitate communication among the participants by managing
discussions and notifying interested parties when issues are edited. One of
the major design goals for Roundup that it be simple to get going. Roundup
is therefore usable "out of the box" with any python 2.1+ installation. It
doesn't even need to be "installed" to be operational, though a
disutils-based install script is provided.

It comes with two issue tracker templates (a classic bug/feature tracker and
a minimal skeleton) and six database back-ends (anydbm, bsddb, bsddb3, sqlite,
metakit and gadfly). 




From theller@python.net  Thu Nov  7 20:00:25 2002
From: theller@python.net (Thomas Heller)
Date: 07 Nov 2002 21:00:25 +0100
Subject: ctypes
Message-ID: <mailman.1036774590.32428.clpa-moderators@python.org>

ctypes is a module allowing to create and manipulate C data types in
Python. These can then be passed to C-functions loaded from dynamic
link libraries.

This module is supposed to be a greatly enhanced and much more
complete replacement of Sam Rushing's calldll/npstruct/windll
modules. ctypes is not based on Sam's work, it has different roots.

It requires Python 2.2 or higher, since it makes intensive use of the
new type system.

----

It provides classes which can be used to create complicated C data
types, for example, those used in Windows type libraries.

Included is a facility to dynamically load DLLs, retrieve functions,
and call them. You can also call methods on COM objects.

Implemented are simple data types (int, char, string, and so on),
function pointers (callbacks), structures, unions, arrays, and
pointers.

ctypes uses win32 structured exception handling, to make it as safe as
possible, although it is clear that it's easy to crash the Python
interpreter.

The source distribution contains an extensive, although inclomplete,
tutorial (which you can also read online), as well as example scripts
demonstrating the use.

One of these scripts contains a dynamic Dispatch implementation, which
is used to drive MS word as an example.

----

ctypes is not yet complete, this is an early release, but IMO it is
already entirely usable. Just don't be too astonished if later
versions have a different behaviour or api.

Homepage: http://starship.python.net/crew/theller/ctypes.html
License: BSD
Platform: Windows (32 bit Intel)

----

Have fun,

Thomas


From greg@cosc.canterbury.ac.nz  Fri Nov  8 02:54:28 2002
From: greg@cosc.canterbury.ac.nz (Greg Ewing)
Date: Fri, 08 Nov 2002 15:54:28 +1300
Subject: ANN: Pyrex 0.4.6
Message-ID: <mailman.1036774590.32437.clpa-moderators@python.org>

Pyrex 0.4.6 is now available:

    http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/

There's just one bug fix in this release, to make
indexing of multi-dimensional C arrays work properly.


What is Pyrex?
--------------

Pyrex is a new language for writing Python extension modules.
It lets you freely mix operations on Python and C data, with
all Python reference counting and error checking handled
automatically.

-- 
Greg Ewing, Computer Science Dept,
University of Canterbury,	
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg



From djc@object-craft.com.au  Fri Nov  8 03:50:30 2002
From: djc@object-craft.com.au (Dave Cole)
Date: 08 Nov 2002 14:50:30 +1100
Subject: csv module 1.0pre1 released (again)
Message-ID: <mailman.1036774590.32463.clpa-moderators@python.org>

Rather than keep you guessing...  This announcement includes some
URLs.

WHAT IS IT:

The CSV module provides a fast CSV parser which can split and join CSV
records which have been produced by Microsoft products such as Access
and Excel.

The module is available here:

    http://www.object-craft.com.au/projects/csv/download/csv-1.0pre1.tar.gz

The module home page is here:

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

NOTES:

The most important change for this release is that the basic quote
handling has been modified to exactly match the observed behaviour of
Excel.  A comprehensive test suite has been added to test this
observed behaviour.  If the module does not conform to Excel behaviour
we consider this to be a bug.

The pre designation on the release is due to the slight change in
quote handling.

CHANGES SINCE 0.5:

* Moved to standard BSD template license.

* Now using distutils to create source distribution.

* Parser's handling of unusual quoting styles was found to be at odds
  with Excel. In particular, Excel only treats the quote character as
  special if it appears as the first character in a field, whereas our
  parser honoured them anywhere. We now produce the same result as Excel -
  quotes within a field appear in the output.

* Introduced Parser.quote_char attribute to replace the hard coded "
  (double quote).  You can now disable quoting by setting quote_char
  to 0 or None.

* Introduced Parser.escape_char attribute which is used to escape
  special characters when quote_char is specified is disabled.

* Introduced Parser.strict attribute which controls whether the parser
  will raise an exception on malformed fields rather than attempting
  to guess the right behaviour.

* Introduced a suite of unit tests.

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



From cognite@zianet.com  Wed Nov  6 22:24:43 2002
From: cognite@zianet.com (cognite@zianet.com)
Date: Wed, 06 Nov 2002 15:24:43 -0700
Subject: new issue 3(1)  of Python Journal at pythonjournal.cognizor.com
Message-ID: <mailman.1036774622.618.clpa-moderators@python.org>

ANNOUNCEMENT, long version.

Python Journal new issue 3(1) at <A HREF="http://pythonjournal.cognizor.com" >
http://pythonjournal.cognizor.com</a>, focusing on several Practical Tasks:  
making a Map Display web app, generating Dynamic Websites, and Text-
Filtering jobs large and small.  Application Design Techniques range from
 deciding how to build your app or a language to customizing 
documents.  

- Digesting online number data to make an image display.
- Multi-pane GUI setup to hold interactive multi-mode 3-D graphs.
- Making a one-file web-services site for single- or multi-thread
usage (via import of standard-library server, or via Apache).
- Embedding a language, using python OOP.  Easy-learn code 
for (ahem!) The Formal Semantics of Python -- in python. 
- Using classes to build an integrated toolset. 
- Integrating other packages into your app.
- Deciding how to build your app.
- Text filters.

The code is as usual pretty straightforward.

ANNOUNCEMENT, ultra-short.

Python Journal 3(1) newly released  at <A
HREF="http://pythonjournal.cognizor.com" >
http://pythonjournal.cognizor.com</a> focuses on Practical Tasks:  Map
Display, Text-Filtering, Dynamic site generation. Bonus: embedded python
engine.  Software from ActiveState.com Python Cookbook,
CherryPy.org, lfw.org, alcyone.com, and users.commspeed.net/tbabbitt/.



From peter@engcorp.com  Sat Nov  9 01:49:20 2002
From: peter@engcorp.com (Peter Hansen)
Date: Fri, 08 Nov 2002 20:49:20 -0500
Subject: Fwd: PyGTA next meeting will be Thursday Nov. 14
Message-ID: <mailman.1036902481.1756.clpa-moderators@python.org>

Peter Hansen wrote:
 >
 > Ian figures we'll be able to have the next meeting in mid-November,
 > barring unexpected setbacks.
 >
 > He or I will post here shortly with an announcement, as soon as
 > something is firm.

I'm happy to announce the next meeting of the recently formed
Toronto Area Python/Zope User Group: PyGTA.

The details of the venue are as follows:

Site: 519 Church St. Community Centre
Room no: TBD (signs will be posted)
Address: 519 Church St., near Wellesley
Date: Thurs. Nov. 14
Time: 8-10 PM

There is metered parking available on Church St. and side streets.
Metered parking spots are free after 9pm.

The site is one block east of the Wellesley subway stop.
There is a Green Spot parking lot on Wellesley,
between Yonge and Church, on the south side.

There are several good pubs including the Keg on Jarvis,
within a block or two of the community center.

Please visit our web site at http://web.engcorp.com/pygta for
further details (unfortunately not updated as I write this, but
I didn't want to delay the announcement any longer).

I'll be posting this note shortly to the PyGTA mailing list
for those who asked to be subscribed.

-Ian Garmaise, Peter Hansen,
  PyGTA organizers



From Rimon Barr <barr@CS.Cornell.EDU>  Sun Nov 10 02:04:40 2002
From: Rimon Barr <barr@CS.Cornell.EDU> (Rimon Barr)
Date: Sat, 9 Nov 2002 21:04:40 -0500 (EST)
Subject: spyce v1.2.5
Message-ID: <mailman.1036902481.1757.clpa-moderators@python.org>

Spyce v1.2.5 released on 9 Nov 2002

SPYCE is a server-side engine that supports simple and efficient
Python-based dynamic HTML generation. Those who like Python and are
familiar with JSP, or PHP, or ASP, should have a look at this engine. It
allows one to generate dynamic HTML content just as easily, using Python
for the dynamic parts. Its modular design makes it very flexible and
extensible. It can also be used as a command-line utility for HTML
pre-processing.

Get it at:
  http://spyce.sourceforge.net

This release includes lots of internal changes. The highlights are:
  - spyceAPI defined: module access to spyceWrapper object restricted
    - see: http://spyce.sourceforge.net/doc-mod_new.html
    - (in general, will be moving towards restricted execution space)
  - toc module improved; add level(), l1()...l9() methods
  - server-level debug option added to config file
    - see: http://spyce.sourceforge.net/doc-conf_common_debug.html
    - debug Spyce module deprecated
  - engine now supports recursive requests (include spyce from itself)
  - sys.stdout (and therefore print statements) made thread-safe
  - spyce engine supports concurrent requests
  - server-level concurrency option added to config file
    - see: http://spyce.sourceforge.net/doc-conf_common_concurrency.html
    - spyce webserver operates in single, forking and threading modes
  - server-level Spyce module caching
    - replaces Spyce-level module caching
    - caching-related code separated from wrapper
  - code compilation seperated from wrapper (spyce.spyceCode)
  - autodetect when PYTHONOPTIMIZE causes lexer/parser failure
  - minor fixes and performance tweaks

For prior release information, view the change log at:
  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/spyce/spyce/CHANGES?rev=HEAD

Comments, suggestions and bug reports are appreciated.

Enjoy,
Rimon.



From tbryan@python.net  Sun Nov 10 02:15:41 2002
From: tbryan@python.net (Tom Bryan)
Date: Sun, 10 Nov 2002 02:15:41 GMT
Subject: TriZPUG November Meeting: Unit Testing in Python
Message-ID: <mailman.1036902482.1758.clpa-moderators@python.org>

The Triangle Zope/Python User Group (TriZPUG) will hold its second meeting 
this Tuesday, November 12, at 6:00 p.m. near Raleigh/Durham, NC.   We will 
be meeting at VERITAS Software, who has kindly permitted us to use their 
meeting room (directions to VERITAS below).  Tom Bryan will give a talk on 
Unit Testing in Python, starting promptly at 6:15.  

Hope to see you there!

Title: PyUnit and doctest: Unit Testing in Python
=================================================
Want fewer bugs in your Python code?  Then test it before the customer or 
even QA sees it!  This talk will define unit testing, convince you that you 
should be doing it, explain Python frameworks that support testing during 
the development cycle, and show you how to use these frameworks.  Learning 
to unit test your code with a standard framework will help you produce 
better code in less time.  

If you aren't testing your code during development, come learn how.  If you 
test your code, but you don't use a framework, come learn the standard ones 
provided with Python.  If you're already a Python unit test guru, come 
heckle the speaker!

Directions to VERITAS:
======================
VERITAS Software, 2530 Meridian Parkway, in Research Triangle Park. The
Meridian Business Park is off of Highway 55, near its intersection with
Interstate 40. 

>From I-40, take exit 278. At the bottom of the exit, turn LEFT onto
Highway 55. 

Turn left at the next light onto Meridian Parkway. 
Travel approximately one-half mile, to building 2530 on the RIGHT. 
Turn RIGHT, and park in the back. VERITAS is on the first floor. 

Go to the Blue Ridge Conference Room, located past the elevators

For more about TriZPUG:
=======================
Web page
http://dev.zope.org/Members/tbryan/TriZPUG/FrontPage
Mailing list
http://starship.python.net/mailman/listinfo/triangle-zpug



From mary-python@puzzling.org  Mon Nov 11 00:12:57 2002
From: mary-python@puzzling.org (Mary)
Date: Mon, 11 Nov 2002 11:12:57 +1100
Subject: Sydney Australia: Python Interest Group: 18th November
Message-ID: <mailman.1037106189.7907.clpa-moderators@python.org>

For our last act in 2002[1], the Sydney Python Interest Group presents:

Andrew Bennetts: "Fun New Stuff in Python 2.2"

"""
Fun new stuff in Python 2.2

An introduction to new language features, including:
  - Iterators
  - Generators
  - Properties, classmethods and staticmethods
  - Type/class unification
  - __new__
  - Metaclasses

This is likely to be a bit of a whirlwind tour of those features, seeing
as we don't have all day. :)
"""

 Date: Monday November 18

 Time: 7:00pm

 Location: University of Technology Sydney, Australia: Broadway campus,
 building 10, room 2.440 (computer lab, on the entrance level). 

-Mary

[1] There will be no PIG meeting in December.

----

See our webpage: http://pig.slug.org.au/ for more details on the Sydney
PIG.

----

SLUG Python Interest Group meetings are announced on:

 * comp.lang.python.announce and python-announce-list@python.org[0]

 * the Australasian Python users list[1]

 * The Sydney Linux User's Group announce list[2]

[0] http://mail.python.org/mailman/listinfo/python-announce-list
[1] http://starship.python.net/mailman/listinfo/python-au
[2] http://lists.slug.org.au/listinfo/announce/

----

The Sydney Python Interest Group is, while not restricted to Python on   
Linux, a Special Interest Group of the Sydney Linux Users Group (SLUG),
and would like to thank SLUG for its support.


From doug.fort@verizon.net  Mon Nov 11 22:07:54 2002
From: doug.fort@verizon.net (Doug Fort)
Date: Mon, 11 Nov 2002 22:07:54 GMT
Subject: fixedpoint 0.1.2 - minor release
Message-ID: <mailman.1037106190.7917.clpa-moderators@python.org>

FixedPoint is Tim Peters' fixed point math class.

It is available on SourceForge at http://fixedpoint.sourceforge.net

This is a minor release to pick up a few things that have been languishing
in CVS because we haven't made any major changes.

1. Added code for compatibility with Python 2.1 (fake 'object' class, etc.)
2. Improved unit tests
3. I tested the unit tests by adding them to 'make test' in the Python 2.2.2
   install. This revealed that fixedpoint.py did not pass TabNanny. 
   I fixed that.

-- 
Doug Fort, Programmer
http://www.dougfort.net


From fmc@inf.ufg.br  Mon Nov 11 15:26:04 2002
From: fmc@inf.ufg.br (Fabio M. Costa)
Date: Mon, 11 Nov 2002 13:26:04 -0200
Subject: Middleware2003 Call for Papers
Message-ID: <mailman.1037108642.12456.clpa-moderators@python.org>

<< Please accept our apologies if you receive multiple copies of this CFP=
 >>

        *************************************************************
        *                                                           *
        *                     Call for Papers                       *
        *                                                           *
        *   ACM/IFIP/USENIX International Middleware Conference     *
        *                                                           *
        *          http://middleware2003.inf.puc-rio.br             *
        *                                                           *
        *         Rio de Janeiro, Brazil, 16-20 June 2003           *
        *                                                           *
        *************************************************************


OVERVIEW
=3D=3D=3D=3D=3D=3D=3D=3D

Requirements for faster development cycles, decreased effort, greater
software reuse, and better end-to-end control over system resources are
motivating the creation and use of middleware and middleware-based
architectures.  Middleware is systems software that resides between the
applications and the underlying operating systems, network protocol
stacks, and hardware.  Its primary role is to (1) functionally bridge
the gap between application programs and the lower-level hardware and
software infrastructure in order to coordinate how parts of applications
are connected and how they interoperate and (2) enable and simplify the
integration of components developed by multiple technology suppliers.

Next-generation distributed applications and systems will increasingly
be developed using middleware.  This dependency poses hard RD challenges,
including latency hiding, masking partial failure, information assurance
and security, legacy integration, dynamic service partitioning and load
balancing, and end-to-end quality of service specification and
enforcement. To address these challenges, researchers and practitioners
need to discover and validate techniques, patterns, and optimizations
for middleware frameworks, multi-level distributed resource management,
and adaptive and reflective middleware architectures.

Building upon the success of past conferences in this series (Lake
District/UK, Palisades/NY, and Heidelberg/Germany), the 4th International
Middleware Conference will be the premier event for middleware research
and technology in 2003.  The scope of the conference is the design,
implementation, deployment, and evaluation of distributed system platform=
s
and architectures for future computing and communication environments.
Highlights of the conference include a high-quality technical program,
tutorials, invited speakers, poster presentations, and workshops, all
held in one of Brazil's most outstanding areas of natural beauty.

The proceedings of Middleware'2003 will be published as a volume of the
Lecture Notes in Computer Science.

TOPICS OF INTEREST
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The topics of this conference include, but are not limited to:

o Distributed real-time and embedded (DRE) middleware platforms
o Reliable and fault-tolerant middleware platforms
o Support for multimedia in middleware platforms
o Novel quality of service (QoS) architectures and evaluation techniques
o Event-based, publish/subscribe and asynchronous middleware platforms
o Open architectures for reconfigurable middleware
o Adaptive and reflective middleware
o Middleware protocols and services for information assurance and securit=
y
o Formal Methods applied to middleware
o Management and use of component-based systems in distributed environmen=
ts
o Applications of middleware technologies, including telematics and
   e-commerce
o Novel paradigms, APIs, and languages for distributed systems
o Integration of middleware with model-integrated computing architectures=
,
   such as OMG MDA
o Extensions and refinements to RM-ODP, CORBA, J2EE, .NET, etc.
o Impact of emerging Internet technologies and standards on middleware
   platforms
o Integration of middleware platforms with Web services and Java
   technologies
o Distributed systems management and interactive configuration and
   development tools
o Issues of scalability in existing and new distributed systems platforms
o Engineering distributed systems in heterogeneous and mobile networks
o Middleware for ubiquitous and mobile computing


ORGANIZATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

General Chair:                Carlos J.P. Lucena (PUC-Rio, Brazil)
Program co-Chairs:            Douglas Schmidt (UC Irvine, USA)
                               Markus Endler (PUC-Rio, Brazil)
Local Arrangements co-Chairs: Alexandre Sztajnberg (UERJ, Brazil)
                               Renato Cerqueira (PUC-Rio, Brazil)
WiP and Posters Chair:        Guruduth S. Banavar (IBM T.J. Watson, USA)
Advanced Workshops Chair:     Gordon Blair (Lancaster University, UK)
Tutorials Chair:              Frank Buschmann (Siemens AG, Germany)
Publicity co-Chairs:          Fabio Costa (UFG, Brazil)
                               Fabio Kon (IME-USP, Brazil)


PROGRAM COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Gul Agha (UIUC, USA)
Jean Bacon (Cambridge U., UK)
Gordon Blair (U. of Lancaster, UK)
Don Box (Microsoft, USA)
Roy Campbell (UIUC, USA)
Andrew Campbell (Columbia U., USA)
Geoff Coulson (Lancaster U., UK)
Naranker Dulay (Imperial College, UK)
Svend Frolund (HP Labs, USA)
Chris Gill (WUSL, USA)
Andy Gokhale (Vanderbilt U., USA)
Rashid Guerraoui (EPF L., Switzerland)
Arno Jacobsen (U. of Toronto, Canada)
Peter Honeyman (CITI U. Michigan, USA)
Fabio Kon (U. of Sao Paulo, Brazil)
Doug Lea (SUNY Oswego, USA)
Guy LeDuc (U. of Li=E8ge, Belgium)
Orlando Loques (UFF, Brazil)
Joe Loyall (BBN Technologies, USA)
Raimundo J.A. Macedo (UFBA, Brazil)
Edmundo R. Madeira (UNICAMP, Brazil)
Jan de Meer (condat AG, Germany)
Klara Nahrstedt (UIUC, USA)
Priya Narasimhan (Carnegie Mellon U., USA)
Carlos Pereira (UFRGS, Brazil)
Vijay Raghavan (DARPA, USA)
Kerry Raymond (DSTC, Australia)
Luis Rodrigues (U. of Lisboa, Portugal)
Isabelle Rouvellou (IBM, USA)
Bill Sanders (UIUC, USA)
Rick Schantz (BBN Technologies, USA)
Alexander Schill (Technical U. Dresden, Germany)
David Sharp (The Boeing Company, USA)
Jacob Slonim (Dalhousie U., Canada)
Jean-Bernard Stefani (INRIA, Grenoble, France)
Joe Sventek (Agilent Labs, UK)
Janos Sztipanovits (Vanderbilt U., USA)
Nalini Venkatasubramanian (UC Irvine, USA)
Steve Vinoski (IONA Technologies, Ireland)
Werner Vogels (Cornell U., USA)
Martina Zitterbart (U. of Karlsruhe, Germany)

SUBMISSION DEADLINES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Full Papers:                                             22 December 2002
Tutorial Proposals:                                      15 January  2003
Work in Progress Papers, Workshop Papers, and Posters :  20 February 2003


MORE INFORMATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For further information, please visit the conference home page:
http://middleware2003.inf.puc-rio.br or, for questions regarding the
conference program, contact the PC chairs, Douglas Schmidt
(schmidt@cs.wustl.edu) or Markus Endler (endler@inf.puc-rio.br).
For other questions contact the local arrangements chairs, Alexandre
Sztajnberg (alexszt@uerj.br) or Renato Cerqueira (rcerq@inf.puc-rio.br).



From wesc@deirdre.org  Tue Nov 12 19:15:39 2002
From: wesc@deirdre.org (Wesley Chun)
Date: Tue, 12 Nov 2002 11:15:39 -0800 (PST)
Subject: ANN: BayPIGgies mtg Wed 11/13 7:30pm
Message-ID: <mailman.1037188082.21275.clpa-moderators@python.org>

BayPIGgies: Silicon Valley-San Francisco Bay Area Python Users Group

When:     November 13, 2002 @ 7:30pm
Where:    Stanford University, Palo Alto, CA
Agenda:   Editing Digital Video using Linux and Python
Speaker:  Drew Perttula

I want to edit digital video in a unix way. That means I want an
open-source suite of non-monolithic, flexible tools and transparent data
formats that I can use with all my other unix tools. I won't stand for any
segfaults or other data-losing behavior. And most of all, I need it by
yesterday.

Development started mid-September, and by late October I was transcribing
and logging captured DV footage into my xml format. Soon after that, the
timeline-style editor was running, and we were dragging thumbnails from
footage index pages (in html displayed in Mozilla) right into the
timeline. There's even the beginning of an effects plugin system, which I
currently use to handle the mixing of audio tracks. At November's meeting,
I'll be demoing the editor itself and discussing the tools I used, the
components I had to build, and where I plan to go with it next.

I have a sloppy wiki site at http://bigasterisk.com/editor where I've put
some screenshots, samples of the xml formats, use cases, and other notes I
made during development. The wiki also gives instructions for getting all
the code via anonymous CVS. The code is still very poorly packaged, so
it's probably near-impossible to get the code to run anywhere else as of
yet.

# Upcoming Meeting: December will be another popular "Newbies Night" (see
April 2002 meeting on the website)

# Call For Talks: We are actively seeking speakers for BayPIGgies! If you
would like to give a talk at one of our 2003 meetings (any Python related
topic), contact us to coordinate!

more info including directions:    http://www.baypiggies.net

hope to see some of you on Wednesday!

-wesley

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

"Core Python Programming", Prentice Hall PTR, =A9 2001
    http://starship.python.net/crew/wesc/cpp/

Silicon Valley-San Francisco Bay Area Python Users Group (BayPIGgies)
    http://deirdre.org/baypiggies

wesley.j.chun :: wesc@deirdre.org
cyberweb.consulting : henderson, nv : cyberweb@rocketmail.com
http://www.roadkill.com/~wesc/cyberweb/



From uche.ogbuji@fourthought.com  Thu Nov 14 01:52:41 2002
From: uche.ogbuji@fourthought.com (Uche Ogbuji)
Date: 13 Nov 2002 18:52:41 -0700
Subject: Article: Proper XML Output in Python
Message-ID: <mailman.1037297194.14183.clpa-moderators@python.org>

http://www.xml.com/pub/a/2002/11/13/py-xml.html

In this article, I methodically thrash out the issues on producing XML
output from Python programs.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Python&XML column: 2. Introducing PyXML -
http://www.xml.com/pub/a/2002/09/25/py.html
The Past, Present and Future of Web Services 1 -
http://www.webservices.org/index.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 -
'http://www.webservices.org/index.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing -
http://www-106.ibm.com/developerworks/xml/library/x-tipgenr.html



From pinard@iro.umontreal.ca  Thu Nov 14 15:18:33 2002
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois?= Pinard)
Date: 14 Nov 2002 10:18:33 -0500
Subject: RELEASED: Pymacs 0.19
Message-ID: <mailman.1037626863.20830.clpa-moderators@python.org>

Hello, my friends.

It has been a long time since the last Pymacs bug!  Here is a new release.

* One may now correctly iterate overs Emacs Lisp lists from Python using a
  short `for' form.  Just for illustrating Pymacs to newcomers, here is a
  simple, but complete example.  Once Pymacs installed, and after putting
  the following file as `essai.py' somewhere on on the Python search path:

     from Pymacs import lisp

     def essai(list):
         for element in list:
            lisp.message('%s' % element)

  the following commands given within in Emacs:

      M-x pymacs-load RET essai RET RET
      M-: (essai-essai '(a b c d)) RET

  will append five lines "'a", "'b", "'c", "'d" and "nil" to the Emacs
  `*Messages*' buffer.  The last "nil" is merely the return value of the
  Python `essai' function.

* On the Emacs side, the function `(pymacs-call FUNCTION ARGUMENT...)' is
  added for convenience.  It works like `pymacs-apply', except that
  arguments are given separately instead of bundled into a single list.

* The documentation has been slightly revised towards Python 2 times.
  For specifying the Emacs interactive behaviour of Python functions, it
  suggests that we prefer function attributes over a global dictionary,
  unless there is a real portability concern for older Python versions.

--------------------

Pymacs is a powerful tool which, once started from Emacs, allows both-way
communication between Emacs Lisp and Python.  Yet, Pymacs aims Python as
an extension language for Emacs rather than the other way around; this
assymetry is reflected in some design choices.  Within Emacs Lisp code,
one may load and use Python modules.  Python functions may themselves
use Emacs services, and handle Emacs Lisp objects kept in Emacs Lisp space.

`http://www.iro.umontreal.ca/~pinard/pymacs/' contains a copy of the
Pymacs documentation in HTML form.  The canonical Pymacs distribution is
available as `http://www.iro.umontreal.ca/~pinard/pymacs/Pymacs.tar.gz'.
Report problems and suggestions to `mailto:pinard@iro.umontreal.ca'.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard


From jdahlin@async.com.br  Thu Nov 14 21:45:28 2002
From: jdahlin@async.com.br (Johan Dahlin)
Date: 14 Nov 2002 19:45:28 -0200
Subject: ANNOUNCE: IndexedCatalog 0.4
Message-ID: <mailman.1037626863.20831.clpa-moderators@python.org>

ANNOUNCE: Released IndexedCatalog 0.4

Async Open Source releases today the third public version of
IndexedCatalog. IndexedCatalog is an extension to the Zope Object
Database (ZODB) that makes object retrieval easier and faster, by
indexing all fields by type (string/integer/float/date) and=20
providing a simple query language.

    http://www.async.com.br/projects/IndexedCatalog/

* Changes

    - New query language:
      * Includes Mike Fletcher's SimpleParse 2.0:
        (code is included to avoid the external dependency)
      * Parentheses
      * Arrays (x in [1, 2, 3])
      * Object references can be used in the query=20
       (using the %o parameter format)
      * Substring case sensitive and case in sensitive matching
      * Boolean operators: and/or/not

    - mx.DateTime support, simplifies date and time indexing/querying
    - Foreign references works correctly now.=20
      (Delegate indexing/queries to other catalogs)
    - Optimized substring searching, should be 10-30% faster.
    - More tests in the test suites.
    - Dynamic attributes for simple types (no instances yet)

Next release will include complete dynamic types, documentation and a=20
(hopefully) stable API.

A blurb about IndexedCatalog follows.

--- blurb -------------------------------------------------------------

* Overview

  IndexedCatalog is an extension to the Zope Object Database (ZODB)
  developed at Async Open Source that provides indexing and allows=20
  queries for objects based on attributes.  This is accomplished=20
  by indexing all fields by type (string/integer/float) and=20
  by implementing a query language.

  IndexedCatalog is licensed under the Lesser GNU Public License (LGPL).

* Features

    - Provides a Catalog class that stores objects and offers a query
      interface.
    - Provides Indexes for Strings, Floats, Integers, Dates and Instances.
    - Requires very little change to objects for catalogs and indexes to
      work: basically inherit from IndexedCatalog.IndexedObject,,=20
      add some special attributes to the Classes, and use catalog.insert(=
)=20
      to add the instances to the catalogs.
    - Supports composite objects, initializing and indexing sub-objects
      automatically.
    - Supports queries by type, and allows querying sub-object or
      referenced object attribute values.
    - Allows ordering query results by field, both ascending and
      descending.
    - Is 100% pure python, and by using Distutils requires
      minimal effort to install.

* Feedback

  We really would appreciate feedback on a few things:

  - The efficiency of the indexing and query algorithms,=20
    especially sub-string matching.
  - The new improved query language
  - All comments are appreciated; don't hesitate to post your
    opinion.

* Download

  You can download IndexedCatalog from

    http://www.async.com.br/projects/IndexedCatalog/

 =20
* Dependencies

  Python 2.1.2 or higher or Python 2.2.2 or higher.
  (Python CVS/2.3 untested)

  ZODB 1.0.x and 3.x are known to work

  eGenix mx Extensions: Currently only mx.DateTime, but we plan to=20
  use larger parts later on.


* Installing

  Using standard python distutils:

    python setup.py install

  Or just set PYTHONPATH to the directory you unpacked IndexedCatalog
  in.


* Reporting bugs

  Report bugs, feature requests and all other things related to
  IndexedCatalog at

    http://bugs.async.com.br/enter_bug.cgi?product=3DIndexedCatalog


* Contact

  Johan Dahlin <jdahlin@async.com.br>
  Christian Reis <kiko@async.com.br>


* About Async

  Async Open Source is a company devoted to developing custom
  applications based on open source software, and providing support for
  other existing open source products. We are active in the OSS
  community, supporting (and employing) project maintainers, encouraging
  release of software as open source, and promoting reuse of existing
  open source products.

  Async is located in S=E3o Carlos, SP, Brazil, and online at
  http://www.async.com.br/

--=20
Johan Dahlin <jdahlin@async.com.br>
Async Open Source



From anthony@computronix.com  Thu Nov 14 23:24:40 2002
From: anthony@computronix.com (Anthony Tuininga)
Date: 14 Nov 2002 16:24:40 -0700
Subject: cx_Freeze
Message-ID: <mailman.1037626863.20832.clpa-moderators@python.org>

Now that I have used these tools internally for a few months I am
pleased to announce the first public release of cx_Freeze, a set of
utilities for freezing Python scripts into executables using many of the
techniques found in Thomas Heller's py2exe, Gordon McMillan's Installer
and the Freeze utility that ships with Python itself.

They are available at
http://www.computronix.com/utilities.shtml

WHY?
Why did I go to the trouble of creating another set of utilities when
these three utilities already existed?  The Freeze utility that comes
with Python itself requires a source distribution, a C compiler and
linker which makes for a complex environment for creating executables.
In addition, this method is very slow for creating executables as
compared to the other methods. Py2exe and Installer both use an import
hook at runtime which means that the development environment and the
runtime environment are considerably different. In addition, py2exe is
only designed to work in the Windows environment and I had needs for
other environments.

HOW?
How does it work? A base executable is created which contains code for
unpacking the list of frozen modules, starting up the Python interpreter
and passing control to the script which is being frozen. When a script
is frozen, the script is searched for all references to modules and
these modules are then byte compiled and written to the end of the base
executable. If the modules that are referenced are extensions written in
C, these modules must be included in the path in which the frozen
executable is deployed.

Comments and suggestions welcome.

-- 
Anthony Tuininga
anthony@computronix.com
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com



From vinay_sajip@yahoo.co.uk  Fri Nov 15 00:56:54 2002
From: vinay_sajip@yahoo.co.uk (Vinay Sajip)
Date: 14 Nov 2002 16:56:54 -0800
Subject: ANN: Logging Package v0.4.7 released
Message-ID: <mailman.1037626864.20833.clpa-moderators@python.org>

A new version of the proposed Python standard logging package (as per
PEP 282) has been released.

What Does It Do?
================
The logging package offers the ability for any Python program to log
events which occur during program execution. It's typically used to
provide application diagnostics, warnings and error messages. In
addition to capturing "what happened", "where it happened", "when it
happened", "how important it is" and event specific data, you can
configure, without changing the application source code, both the
verbosity of logging and the routing of events to different
destinations such as console, disk files, sockets, email addresses,
Web servers, SOAP servers etc. etc. You can even change the
configuration of a running program without stopping and restarting it!

You can use the logging package in exception handlers, and it will
include traceback information in the log. It's thread-safe, and very
easy to use - just "import logging" and log away! Classes provided
include:

Logger	- used to log messages for a particular area of an application.
You can instantiate these wherever you want, there's no need to pass
references to them around your application. You can log events based
on importance levels of DEBUG (least important), INFO, WARN, ERROR,
and CRITICAL (most important). You can define your own levels if the
default levels don't meet your requirements.

Handler - used to route events to particular destinations. Handlers
included are:
   StreamHandler (for generalized streams, including console)
   FileHandler (for disk files - including log file rotation with size
limits for log files)
   SocketHandler (for sending events to a TCP socket)
   DatagramHandler (for sending events to a UDP socket - faster, but
less reliable than TCP)
   SMTPHandler (send events to arbitrary email addresses)
   HTTPHandler (send events to Web servers)
   SysLogHandler (send events to Unix syslog)
   MemoryHandler (batch up events and process them several at a time)
   NTEventLogHandler (send events to Windows NT event logs)
   
There are also examples of XMLHandler and SOAPHandler in the
distribution.

Formatter - used to format events as text strings. Flexible "msg %
arg_tuple" formatting is the basis for formatting, with flexible
date/time formatting including ISO8601 and any strftime-based formats.

Filter - used when filtering based on importance
(DEBUG/INFO/WARN/ERROR/CRITICAL) is not sufficient. The distribution
includes examples of filters based on class matching, regular
expression matching, value matching, and logger matching.

In the unlikely event that you're daunted by all the apparent
complexity, fear not. The package offers a simple function-based
interface to allow very simple, almost casual use of the underlying
features.

In addition to the core logging functionality, you get the ability to
configure logging using a ConfigParser-based text file format, a
Tkinter-based GUI configurator which creates configuration files for
you, and a simple network-based event receiver which receives events
on TCP, UDP, HTTP and SOAP ports. This is suitable for testing and
might perhaps serve as a model for your own event receivers. Also
included are over 20 test scripts which serve both as test harnesses
and examples of how to use the logging package.

You can get more information from

http://www.red-dove.com/python_logging.html

There are "download" and "recent changes" links at the top of that
page. The new stuff includes some bug fixes, better support for
class-based filtering and logging, more documentation of the
configuration file format, an example hand-coded configuration file
for those people who can't use the GUI configurator, an example Filter
for regular-expression match-based filtering, and more!

As always, your feedback is most welcome (especially bug reports,
patches and suggestions for improvement). Enjoy!

Cheers

Vinay Sajip
Red Dove Consultants Ltd.

Changes since the last version:
=================================
Made into a package with three modules: __init__ (the core code),
handlers (all handlers other than
FileHandler and its bases) and config (all the config stuff). Before
doing this:
Updated docstrings to include a short line, then a blank line, then
more descriptive text.
Renamed 'lvl' to 'level' in various functions.
Changed FileHandler to use "a" and "w" instead of "a+" and "w+".
Moved log file rotation functionality from FileHandler to a new class
RotatingFileHandler.
Improved docstring describing rollover.
Updated makePickle to use 4-byte length and struct module, likewise
logrecv.py. Also updated on-the-fly
config reader to use 4-byte length/struct module.
Altered ConfigParser test to look at 'readline' rather than 'read'.
Added optional "defaults" argument to fileConfig, to be passed to
ConfigParser.
Renamed ALL to NOTSET to avoid confusion.
Commented out getRootLogger(), as obsolete.
To do regression testing, run log_test.py and compare the created
files stdout.log and stderr.log against
the files stdout.exp and stderr.exp. They should match except for a
couple of exception messages which give absolute file paths.
Updated python_logging.html to remove links to logging_pydoc.html,
which has been removed from the
distribution.
Changed default for raiseExceptions to 1.


From Marc.Poinot@onera.fr  Fri Nov 15 09:20:13 2002
From: Marc.Poinot@onera.fr (Marc Poinot)
Date: Fri, 15 Nov 2002 10:20:13 +0100
Subject: pyCGNS v0.6
Message-ID: <mailman.1037626864.20834.clpa-moderators@python.org>

-----------------------------------------------------------------------
pyCGNS v0.6

This package is a Python wrapper for CGNS (http://www.cgns.org)
It is useful for people doing archival, data exchange or pre/post
processing on CFD (Computational Fluid Dynamics) data.

-----------------------------------------------------------------------
This release has two new tools and includes a proposal for a CGNS DTD:

cgl   - a kind of 'ls', filters information found in the CGNS files
sift  - an XML validator which can be used to check the CGNS compliance
        of a given tree. 

-----------------------------------------------------------------------
Package pyCGNS uses CGNS, Python, Numeric Python and pyXML.
If you want more info, including the package download, please go to:

  http://elsa.onera.fr/CGNS/releases

-MP- 
-----------------------------------------------------------------------
 Marc POINOT             Alias: marcvs        Email: poinot@onera.fr
 ONERA -MFE/DSNA/ELSA    Tel: 01.46.73.42.84  Info: elsa-info@onera.fr
 29, Div. Leclerc        Fax: 01.46.73.41.66  Site:     
 92322 Chatillon FRANCE  Project: elsA        Web: http://www.onera.fr


From Rimon Barr <barr@CS.Cornell.EDU>  Fri Nov 15 14:29:44 2002
From: Rimon Barr <barr@CS.Cornell.EDU> (Rimon Barr)
Date: Fri, 15 Nov 2002 09:29:44 -0500 (EST)
Subject: spyce v1.2.7
Message-ID: <mailman.1037626865.20835.clpa-moderators@python.org>

Spyce v1.2.7 released on 15 Nov 2002

SPYCE is a server-side engine that supports simple and efficient
Python-based dynamic HTML generation. Those who like Python and are
familiar with JSP, or PHP, or ASP, should have a look at this engine. It
allows one to generate dynamic HTML content just as easily, using Python
for the dynamic parts. Its modular design makes it very flexible and
extensible. It can also be used as a command-line utility for HTML
pre-processing.

Get it at:
  http://spyce.sourceforge.net

This release continue the internal restructuring of the engine code, which
has resulted in some performance improvements. This is almost done now,
and I will refocus on features. Some modules may have been broken, but
should not be difficult to fix to conform to the new API. The
documentation will be updated shortly. The highlights sice v1.2.6:
  - internal restructuring continues
    - separated spyce exceptions
    - separated spyce configuration
    - expanded spyce API and spyceServer
    - spyce.spyceDone now imported as spyceDone
  - simplified spyceModule
    - renamed wrapper field, to _api
    - old spyceModule available as spyceModulePlus
    - all standard modules updated
  - fixed - syntax errors were not reported properly sice v1.2.4
  - file-based spyce caching, with config option
  - performance improvements

For prior release information, view the change log at:
  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/spyce/spyce/CHANGES?rev=HEAD

Perhaps most importantly, I have spent a considerable time to test this
release, and I expect it to be quite stable. Comments, suggestions and bug
reports are appreciated.

Enjoy,
Rimon.



From jason@tishler.net  Fri Nov 15 16:40:50 2002
From: jason@tishler.net (Jason Tishler)
Date: Fri, 15 Nov 2002 11:40:50 -0500
Subject: Updated Cygwin Package: python-2.2.2-1
Message-ID: <mailman.1037626866.20836.clpa-moderators@python.org>

New News:
=== ====
I have updated the version of Python to 2.2.2-1.  The tarballs should be
available on a Cygwin mirror near you shortly.

The _socket module is still being built static instead of shared to
workaround a fork() issue with DLL base address conflicts.  See the
README for more details.

Old News:
=== ====
Python is an interpreted, interactive, object-oriented programming
language.  If interested, see the Python web site for more details:
                                                                   
    http://www.python.org/                                         

Please read the README file:
                            
    /usr/doc/Cygwin/python-2.2.2.README

since it covers requirements, installation, known issues, etc.

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

Note that we have recently stopped downloads from sources.redhat.com
(aka cygwin.com) due to bandwidth limitations.  This means that you will
need to find a mirror which has this update.

In the US,
ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/
is a reliable high bandwidth connection.

In Germany,
ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/
is usually pretty good.

In the UK,
http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/
is usually up-to-date within 48 hours.

If one of the above doesn't have the latest version of this package
then you can either wait for the site to be updated or find another
mirror.

The setup.exe program will figure out what needs to be updated on your
system and will install newer packages automatically.

If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6


From boud@valdyas.org  Sat Nov 16 15:12:24 2002
From: boud@valdyas.org (Boudewijn Rempt)
Date: Sat, 16 Nov 2002 16:12:24 +0100
Subject: Kura 2.0 released.
Message-ID: <mailman.1037626866.20837.clpa-moderators@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                          Kura 2.0 
- ------------------------------------------------------------------
I am pleased to announce the second release of Kura.

Kura is a complete system for the handling of linguistic data, especially
fieldwork data from small-corpus languages. It allows users to enter
texts in any language, analyze those texts and bring the analyzed
linguistic facts into relation with each other. 

This is the second full release of Kura for Unix/X11. Kura no longer supports
Windows.

Kura is available at:

   http://www.valdyas.org/linguistics/index.html
   
There is both an rpm package and a tarball:

   http://www.xs4all.nl/linguistics/kura-2.0-1.rpm
   http://www.xs4all.nl/linguistics/kura-2.0.tgz

Features

New in this release are:
  
  * Support for files to store data. MySQL is still fully supported.
  * port to Qt 3.x (which means better Unicode support).
  * A very complete manual.
  * Dropped support for parse sets.
  * An improved interlinear text editor.
  * Drag and drop from Kura to editors.
  * Export to docbook sgml.
  * Many, many bugfixes.

Kura uses the following run-time components: MySQL, MySQLdb,
Python, PyQt.  MySQL is no longer absolutely necessary.

License

Kura is free software and distributed under the Python license.
This means that anyone can download and use Kura for free,
anyone can alter Kura to his or her own liking and distribute
the altered version free or for profit. However any changes must
be contributed back to the me, and I have the right to incorporate
those changes in new, free versions of Kura.
- ------------------------------------------------------------------


Boudewijn Rempt | boud@valdyas.org

<P><A HREF="http://www.valdyas.org/linguistics">Kura 2.0</A>
 - Kura is an application for the analysis and presentation of linguistic
 data.  (16-Nov-2002)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE91mBYdaCcgCmN5d8RAsTgAKDN5EwgfcFRPDNFdIVGXgJjJXPvJQCWOhIF
ByhGse+knV3Lvg+Iu11+Ng==
=byP/
-----END PGP SIGNATURE-----



From skip@pobox.com  Sun Nov 17 03:46:57 2002
From: skip@pobox.com (Skip Montanaro)
Date: Sat, 16 Nov 2002 21:46:57 -0600
Subject: Python-friendly Web Hosting Wiki
Message-ID: <mailman.1037626866.20838.clpa-moderators@python.org>

A new Wiki page devoted to Python-friendly web hosting services is available
on the Python.org website.  This page replaces the previously static page
which wasn't getting properly updated due to lack of time on someone's part.
If you use or manage a service you feel deserves to be mentioned, click on
over to

    http://www.python.org/cgi-bin/moinmoin/PythonHosting

and check it out.  There is plenty of online help available for people using
a Wiki for the first time.  If you have feedback or questions, send them
along to webmaster@python.org.

-- 
Skip Montanaro - skip@pobox.com
http://www.mojam.com/
http://www.musi-cal.com/


From drifty@bigfoot.com  Mon Nov 18 05:00:32 2002
From: drifty@bigfoot.com (Brett C.)
Date: 17 Nov 2002 21:00:32 -0800
Subject: python-dev Summary, 2002-11-01 through 2002-11-15
Message-ID: <mailman.1037626867.20842.clpa-moderators@python.org>

==================================================
python-dev Summary, 2002-11-01 through 2002-11-15
==================================================

This is a summary of traffic on the `python-dev mailing list`_ between
November 1, 2002 and November 15, 2002 (inclusive).  It is intended to
inform the wider Python community of on-going developments on the list
that might interest the wider Python community.  To comment on
anything mentioned here, 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 something.  And if all of this really
interests you then get involved and join python-dev!

This is the fifth summary written by Brett Cannon (after a relaxing
two week hiatus; thanks to Raymond Hettinger for doing the Summary
while I was gone).

All summaries are now archived at http://www.python.org/dev/summary/
(thanks to A.M. Kuchling for setting that up).

Please note that this summary is written using reStructuredText_ which
can be found at http://docutils.sf.net/rst.html .  Any unfamiliar
punctuation is probably markup for reST_; you can safely ignore it
(although I suggest learning reST; its simple and is accepted for PEP
markup).  Also, because of the wonders of programs that like to
reformat, I cannot guarantee you will be able to run the text version
of this summary through Docutils_ as-is.  If you want to do that, get
an original copy of the text file.

.. _python-dev mailing list:
http://mail.python.org/mailman/listinfo/python-dev
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html

======================
Summary Announcements
======================

Not much to say for this summary.  The only thread skipped that
someone out there might care about was one on getting the PEPs to
display properly for IE 6 when the PEP was written in reST_.

Thanks goes to Raymond Hettinger for covering the Summary while I was
away on vacation.  Thanks also goes out to Laura Creighton and Guido
for suggesting graduate schools that are Python-friendly.

Michael Chermside was the only person to respond directly to my
question as to whether anyone had issue with me injecting my
personality into the summary.  But he said to go ahead and let me
personality permeate throughout this thing, so it will.  Let that be a
lesson to anyone who wanted me to shut up and be drab; had you and a
friend spoken up this little tirade would not be happening.  =)



=================================
`Getting python-bz2 into 2.3`__
=================================
__ http://mail.python.org/pipermail/python-dev/2002-November/029830.html

Continuation of http://mail.python.org/pipermail/python-dev/2002-October/029829.html

Gustavo Niemeyer asked how he should go about getting his python-bz2_
module into the standard library.  He was basically told to submit a
patch complete with the module, docs, regression tests, etc.;
everything a healthy module needs.  It was also suggested that he
provide a MSVC project file.

That didn't work for Gustavo (who now has CVS write priveleges;
congrats) since he doesn't use Windows.  This was a slight problem
because if the extension file doesn't build under Windows it can't be
included in the PythonLabs Windows distro.  So keep in mind that if
your module won't directly compile for 6 different versions of Windows
it won't be included in the Windows distro.

.. _python-bz2: http://python-bz2.sourceforge.net/

===================================
`Becoming a python contributor`__
===================================
__ http://mail.python.org/pipermail/python-dev/2002-November/029831.html

Continuation of http://mail.python.org/pipermail/python-dev/2002-October/029828.html

Gustavo Niemeyer asked about how he could help contribute to Python. 
He made the observation that "Guido and others [have been] bothered a
few times because of the lack of man power" which has led to a "small
core of very busy developers working on core/essential/hard stuff
*and* in code reviewing as well" (and I can attest to this fact that
this is very true; I am amazed the guys at PythonLabs have any form of
a life outside of work with the amount of time they put in).  Gustavo
felt "that the Python development is currently overly centralized".

Martin v. Loewis responded first.  He said that "the most important
aspect I'd like to hand off is the review of patches; to Tim, it is
the analysis of bug reports".  Martin then listed various points on
how to be able to review a patch and how to handle bug reports; the
email is at http://mail.python.org/pipermail/python-dev/2002-November/029831.html
.  I *highly* recommend reading the email because Martin's points are
all good and more patch reviewers would be rather nice.

M.A. Lemburg commented next, saying that he "wouldn't mind if other
developers with some time at hand jump in on already assigned patches
and bug reports to help out".  Just because a patch has been assigned
to someone doesn't mean the patch or the assignee couldn't use more
help.  Having the patch assigned to someone just means that they take
responsibility to apply the patch if it is worthy of being accepted or
to reject it.  It should not stop other people from making comments or
helping out so that the assignee can have a little bit of time saved
for other things... like another patch to assign to themselves.  MAL
also suggested that we have more maintainers that are in charge of
chunks of code, e.g. Martin handles all locale code.

Martin disagreed with this idea, though.  Jack Jansen agreed with
Martin.  He thought that if something came up that was not within the
realm of a specific person that it "either get[s] ignored, or passed
on to Guido, or picked up by yourself or Michael [Hudson] or one of
the very few other people who do general firefighting".  Martin
commented later that he would hope that the stewardship of specific
code does not get any more formal.

Martin then stated how one goes about getting commit priveleges for
Python on SF: "just step forward and say that you want. In the past,
Guido has set a policy that people who's commit privilege is fresh
will still have to use SF, but can perform the checkin themselves". 
Tradition has stated that "fresh" is your first two or three SF
patches.  But please only step forward if you are known to python-dev
or PythonLabs since commit priveleges won't be given to people who
just wander in off the proverbial street and ask for it.  Martin
basically states this in a later email by saying that "people should
not produce a burst of patches just to get commit privileges. Instead,
they should contribute patches steadily (and should have done so in
the past), and then get CVS write access as a simplification for the
rest of the maintainers".

Neal Norwitz pointed out that if a bug ends up with a fix it is best
to submit a separate patch instead of attaching it to the bug report. 
That way there is a bigger chance of the patch being seen and dealth
with.  But please make sure to mention that it fixes a bug so that the
bug can be closed!  Martin even suggested mentioning this fact in the
title of the patch submission.

====================
`RoundUp status`__
====================
__ http://mail.python.org/pipermail/python-dev/2002-November/029879.html

This is a splinter thread of the 'Becoming a python contributor'
thread in which Micheal Hudson asked how using Roundup_ for replacing
SF_ was coming along.  Guido said things had come up that was holding
it up.  One was that the test server running at
http://www.python.org:8080 had died when the box was restarted (it is
now back up).  There were also some changes to Roundup that needed to
be dealt with in order to get everything over from SF on to Roundup. 
Guido also just ran out of time to review it more, although he did
like what he had reviewed so far.  Guido asked for a volunteer.

It was asked what was needed.  Guido said that Roundup had moved over
to Zope-style templating so all the old templates that Gordon (I
assuming this is Gordon McMillan) wrote needed to be changed.  There
were also some bugs that needed to be dealt with that are being
tracked at Roundup hosted at http://www.python.org:8080 .  And there
also will need to be preparations for the day that development is
moved over from SF to the Roundup setup; that will require
transferring everything over from SF, shutting down SF, and handling
any bugs that crop up from the heavy use that the new setup is going
to get.

So if you have any dislike for SF, then please contribute to Roundup
and help get Python off of there!

.. _Roundup: http://roundup.sourceforge.net/
.. _SF: http://www.sf.net/

=======================================
`Contributing...current bug status`__
=======================================
__ http://mail.python.org/pipermail/python-dev/2002-November/029846.html

Neal Norwitz went through the SF_ bug tracker and counted 325 bugs and
generated a very easy to read page listing all the bugs with their
relevant info.  You can find the HTML version at
http://www.metaslash.com/py/sf.data.html .  If you find a bug there
you think you can help out on, then go to SF and do so!

=======================
`Low hanging fruit`__
=======================
__ http://mail.python.org/pipermail/python-dev/2002-November/029850.html

Neal Norwitz generated a list of what he thought were easily fixable
bugs and put them in this thread (it's the first email so just go to
the link for this thread).  So if you have a little bit of free time
and want to help out why don't you try to tackle one of these bugs?

===============
`Snake farm`__
===============
__ http://mail.python.org/pipermail/python-dev/2002-November/029853.html

The only reason I am mentioning this thread here is to help get the
word out about the `Snake Farm`_ ; hosted by Lysator_ and sponsored by
the `Python Business Forum`_ .  It is a compile farm that downloads
from CVS, compiles, and runs the test suite of Python daily.  It has
caught a bunch of bugs and has been a great help.

The majority of the thread was spent trying to get FreeBSD 4.4 to
compile Python and trying to work out a possible bug in pymalloc.

.. _Snake Farm: http://www.lysator.liu.se/~sfarmer/
.. _Lysator: http://www.lysator.liu.se/
.. _Python Business Forum: http://www.python-in-business.org

====================================
`David Goodger joins PEP editor`__
====================================
__ http://mail.python.org/pipermail/python-dev/2002-November/029866.html

David Goodger has somehow gotten suckered into becoming a PEP editor
(I suspect Barry Warsaw had something to do with this since he used to
do all of the PEP editing).  So you can all welcome David to his new
responsibility by flooding him with all of those PEPs you have lying
around and were not sure were good enough to submit.  =)

========================
`metaclass insanity`__
========================
__ http://mail.python.org/pipermail/python-dev/2002-November/029872.html

Continuation of http://mail.python.org/pipermail/python-dev/2002-October/029795.html

Michael Hudson posted the question as to how to get writing
``__bases__`` for new-style classes to do the "right thing" since the
mro does not seem to be updated.  Kevin Jacob gave it a go but ran
into a bug.

Guido said that currently there is no way to touch the MRO from Python
code.  All of that info is stored in the tp_mro slot in the object's C
representation and is stored as a tuple whose members are expected to
be either types or classic classes.  Guido said he would accept a
patch for assigning to the mro if a check was included to make sure
the previously mentioned constraint was maintained.  He also said he
would probably accept a patch that allowed for assignable
``__bases__`` and writing ``__name__`` .

Michael Hudson commented about the difficulty of all of these patches.
 One thing that came up was the connection between ``__bases__`` and
``__base__`` and how assignment to ``__base__`` should not be taken
lightly; Guido commented that "the old and new base must be layout
compatible, exactly like for assignment to __class__".

Guido later pointed out that ``__base__`` becomes the built-in type
that you derive from; whether it be object, list, dict, etc.  It was
agreed that ``__base__`` shouldn't be writable.

The point was made that nestable classes are not picklable since only
thing at the top level of a module can be pickled.  Guido said he
considered this a flaw although he couldn't think of why someone would
want to embed a class within a class or a function.  This spawned
comments on how to deal with this.  It seemed the best solution was to
change ``__name__`` for the inner class to a fully dotted name (e.g.
``X.Y.__name__ = "X.Y"``) and then make a simple change to either
``pickle`` or ``getattr()``.  It was eventually agreed upon that
setting ``__name__`` to the full dotted name of the class was the best
solution and it was filed as `bug #633930`_ .

As part of trying to give Guido good examples of why nested classes
are good (the best attempt was Walter Dorwald in an email at
http://mail.python.org/pipermail/python-dev/2002-November/029906.html
that elicited a "that's cool" comment from Guido), the idea of having
``__iter__`` contain a class definition that returned an instance of
that class came up.  That was shot down because of the performance hit
of dealing with the class definition on every call to ``__iter__``. 
But the idea of defining ``__iter__`` as a generator was pointed out
by Just van Rossum.  Doing that simplifies the code usually a good
amount since the generator handles all ``.next()`` calls and you just
need to have the generator stop when you want your iterator to stop. 
Apparently this is not a widely used idiom, so I am mentioning it here
since it is a great idea that I can personally attest to as being a
rather nice way to handle iterators.

.. _bug #633930: http://www.python.org/sf/633930

============================
`[#527371] sre bug/patch`__
============================
__ http://mail.python.org/pipermail/python-dev/2002-November/029936.html

I am mentioning this thread not because the bug is that big of a deal,
but because of the PEP that was brought up when dealing with the bug;
`PEP 291`_ .  This informational PEP, among other things, lists
modules that must be kept compatible with certain versions of Python;
in this case sre has to be kept compatible with Python 1.5.2.  Except
for sre, they are all packages that have made their way into the
library.  You might want to have a look at the list if you are hacking
on any packages in the stdlib.

.. _PEP 291: http://www.python.org/peps/pep-0291.html

======================================================================
`Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]`__
======================================================================
__ http://mail.python.org/pipermail/python-dev/2002-November/029941.html

Once again this is not to meant to mention directly what as discussed
in the thread but a point made.  The bug that was discovered was an
issue with 64-bit machines and the 32-bit limitation of lists and
slicing.  The 32-bit limit currently is hard-coded into the C code. 
Obviously some people would like to see this changed.

Neal Norwitz laid down a rough outline on how one could go about
changing this at http://mail.python.org/pipermail/python-dev/2002-November/029953.html
.  Guido then made a pronouncement later stating that he is willing to
break binary compatibility once for Python 2.3 or 2.4 to get this
done.  He also mentioned some other things to make sure to do.

As of this writing no one has stepped forward to take this on.

==============================
`Reindenting unicodedata.c`__
==============================
__ http://mail.python.org/pipermail/python-dev/2002-November/029997.html

While doing some work on `Modules/unicodedata.c`_ , Martin v. Loewis
noticed that the indentation style didn't follow `PEP 7`_ and he
wondered if it would be okay to re-indent the file.  This brought up
two points.

One was that PEP 7 was not stringently followed.  The PEP says to "Use
single-tab indents, where a tab is worth 8 spaces".  Now that goes
against Python coding style where you are supposed to use 4-space
indents.  So the question of whether one should still use the tab
style in new C code came up.  Guido said he wished new C code would,
but for files he doesn't touch very often he doesn't feel he can
enforce it.  Barry and Martin came up with an Emacs "local variables"
stanza for the bottom of any file that uses a non-PEP style which can
be found at http://mail.python.org/pipermail/python-dev/2002-November/030067.html
.  But following the PEP is still the "officially" supported style. 
But you should try to follow PEP 7 for all new C code and PEP 8 for
Python code.

The other point was when to re-indent.  It was agreed upon to only do
that when a major change in the code was occuring.  And when you do
re-indent, do it as a separate check-in for CVS.

.. _Modules/unicodedata.c:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/unicodedata.c
.. _PEP 7: http://www.python.org/peps/pep-0007.html

=============================
`Printing and __unicode__`__
=============================
__ http://mail.python.org/pipermail/python-dev/2002-November/030098.html

Martin v. Loewis brought up a point made by Henry Thompson on c.l.py
asking why printing ignores ``__unicode__``.  Martin thought it
shouldn't and listed a bunch of options on how to make printing work
with ``__unicode__``.  The winner was to have "A file indicates
"unicode-awareness" somehow. For a Unicode-aware file, it tries
``__unicode__``, ``__str__``, and ``__repr__``, in order".  The agreed
solution was to add an ``.encoding`` attribute.  This attribute can be
set to None when the stream is in Unicode and never converts to a
byte-stream.

But then M.A. Lemburg chimed in.  He was fine with the addition of the
``.encoding``; "this attribute is already available on stream objects
created with codecs.open()".  What he didn't like was having
``.encoding`` set to None mean the stream would accept Unicode. 
Martin asked then if ``StringIO`` should have ``.encoding``.

MAL replied that "``StringIO`` should be considered a non-Unicode
aware stream, so it should not implement .encoding".  He thought that
if someone wanted ``StringIO`` to be Unicode-aware they could use "the
tools in codecs.py [since they] can be used for this (basically by
doing the same kind of wrapping as ``codecs.open()`` does)".  But then
Martin pointed out that StringIO is already Unicode-aware.

This debate continued between MAL, Martin, and Guido.  But then Guido
just said he gave up since the current behavior was relied upon too
much.

===================
`Adopting Optik`__
===================
__ http://mail.python.org/pipermail/python-dev/2002-November/030108.html

Splinter threads:
	- `Re: [getopt-sig] Adopting Optik
<http://mail.python.org/pipermail/python-dev/2002-November/030154.html>`__
	- `Re: Adopting Optik
<http://mail.python.org/pipermail/python-dev/2002-November/030189.html>`__
	- `Fw: [Python-Dev] Adopting Optik
<http://mail.python.org/pipermail/python-dev/2002-November/030165.html>`__
	- `[getopt-sig] Re: [Python-Dev] Adopting Optik
<http://mail.python.org/pipermail/python-dev/2002-November/030179.html>`__

Guido sent an email saying that he would like to get Python 2.3a out
the door by X-mas.  This means trying to come up with a new name for
Optik_ , Greg Ward's command-line options parser.  The complaint about
the current name is that it's too cute.  Guido started it by
suggesting the name ``options``.

Peter Funk brought up two things.  One was that Docutils already used
the module under its Optik name.  To this Guido responded that they
could just change the name in the code.  Peter also said that Greg
liked ``OptionsParser``.  There was also the point that module names
are preferred to be short and lowercase.

Ka-Ping Yee and myself brought up the point that ``options`` is very
generic.  Guido agreed with this point while also mentioning that many
people already have their own modules named options.py.  He then
suggested ``optlib`` since "It's short, un-cute, and follows the \*lib
pattern used all over the Python stdlib".  Greg Ward liked this
suggestion.

I personally suggested ``ArgParser``, trying to get a tie-in for
sys.argv.  Greg Ewing built off of this and suggested ``argvparse``,
similar to ``urlparse``.  David Ascher preferred ``argparse`` since
"The v is archaic and so silent it fades away =)".  David Abrahams
disagreed, stating how the "v" deals with any ambiguity.  David
Abrahams also said he would vote for ``argvparse`` to break a tie.

Ka-Ping Yee suggested ``cmdline`` and ``cmdopts``.  David Abrahams
liked both.

Steve Holden built off of Guido's ``optlib`` and pushed for
``optionlib``.

Raymond Hettinger threw ``OptionParser`` into the ring.

But then Guido asked for a call to votes between ``optlib`` and
``argvparse``.  I tallied the votes at one point with it kind of split
between them.  Then Guido announced that ``optparse`` won (and no,
that is not a typo).

.. _Optik: http://optik.sf.net/

===========================
`Killing off bdist_dumb`__
===========================
__ http://mail.python.org/pipermail/python-dev/2002-November/030139.html

Splinter threads:
	- `RE: [Distutils] Killing off bdist_dumb
<http://mail.python.org/pipermail/python-dev/2002-November/030153.html>`__
	- `E: [Distutils] Killing off bdist_dumb
<http://mail.python.org/pipermail/python-dev/2002-November/030219.html>`__

A.M. Kuchling asked if anyone would mind if bdist_dumb was removed
from distutils (the conversation also happened with `distutils-sig`_
).  Apparently it is rather broken in terms of the paths of the files
because it makes them all relative.  M.A. Lemburg, though, spoke up
stating that he uses bdist_dumb.  It still wasn't fully resolved as of
this writing.

The point of being able to build bdist_wininst on non-Windows
platforms came up during this discussion as well.  It was decided to
move the binary files needed for bdist_wininst into CVS (now filed as
`bug #638595`_ ).

.. _distutils-sig: http://www.python.org/sigs/distutils-sig/
.. _bug #638595: http://www.python.org/sf/638595

===============================================
`Python interface to attribute descriptors`__
===============================================
__ http://mail.python.org/pipermail/python-dev/2002-November/030118.html

Splinter threads:
	- `Python interface to attribute descriptors 
<http://mail.python.org/pipermail/python-dev/2002-November/030213.html>`__

Paul Dubois decided to cause himself some grief and attempt to
comprehend the miracle that is descriptors (more info can be found in
the `2.2.2 What's New`_ doc and in `PEP 252`_).  He was wondering if
there was more documentation than the signatures of the functions for
the C API.  He also wanted to know if there was a way to play with
them in the Python world since all of his attempts fell short of them
being "first-class citizen from Python".

Guido admitted that the docs were lacking.  He then asked for some
help in writing the docs.  He responded to Paul's second question by
saying that he thought it should work as long as you avoided classic
classes.

Thanks to Guido saying that is should work, Paul realized that he
misread the PEP.  To be nice he emailed out an example of how a
descriptor could know where it came from at
http://mail.python.org/pipermail/python-dev/2002-November/030141.html
.  Phillip Ebey also chimed in on how to write a metaclass that said
the name of the descriptor at
http://mail.python.org/pipermail/python-dev/2002-November/030213.html
.

.. _2.2.2 What's New:
http://www.python.org/doc/2.2.2/whatsnew/sect-rellinks.html#SECTION000320000000000000000
.. _PEP 252: http://www.python.org/peps/pep-0252.html

==============================
`IDLE local scope cleanup`__
==============================
__ http://mail.python.org/pipermail/python-dev/2002-November/030124.html

Patrick O'Brien (author of PyCrust_ ) wondered how IDLE managed to
keep its local scope so clean once it finished launching.  Guido said
that IDLE (or at least the GRPC version which Patrick O'Brien believes
stands for Generalized Remote Procedure Call) runs the shell in a
subprocess that is careful not to pollute the namespace.

Patrick thanked Guido and then presented his real question: how to
handle not polluting the namespace with a way getting around a
pickling issue.  He "used to just pass a regular dictionary to
code.InteractiveInterpreter, which worked well enough", but there was
an issue with pickling.  So then he tried passing
``sys.modules['__main__'].__dict__``, which worked but cluttered the
namespace.

Guido's response: "Remove the clutter".  Guido said that this would
most likely require a minimalistic main program that bootstrapped
using ``__import__('run').main()`` which would run the code without
adding to the namespace.

.. _PyCrust: http://www.orbtech.com/wiki/PyCrust


From gandalf@python.eu.org  Mon Nov 11 03:25:33 2002
From: gandalf@python.eu.org (Vladimir Ulogov)
Date: Sun, 10 Nov 2002 22:25:33 -0500 (EST)
Subject: [Application] YODA distributed objectstore ver 1.1
Message-ID: <mailman.1037626870.20852.clpa-moderators@python.org>

                  YODA distributed objectstore ver 1.1                  
                  ------------------------------------                  

Distributed objectstore with Pyro and XMLRPC interfaces

Version 1.1 are considered as a "base" version. This means I'd
implemented most of the planned YODA functionality at this point.
Respective user will get truly distributed objectstore, where the single
objectstore can live on multiple instances. Each instance can replicate
there objects to multiple peers. All updates are reflected in
METADIRECTORY. The newly implemented "YODA interface appication"
provides you transparent access to the information stored in distributed
objectstore without knoweledge which physical repository holds it. If
the one of repository failed and object can be found someplace else (in
the replica repository), YODA will find and extract this information for
you "at no extra cost". The same rule applies to the all update
operations, you just set the value of the attribute and YODA will take
care about the rest. Actually, it it a pretty heavy job going on in the
background. YODA interface detects which repositories are alive and
which is not by sending event broadcast, than it's propagate updates on
the live servers. YODA interface provides two ways to access to the
objectstore: - native YODA interface (which means Pyro:
http://pyro.sourceforge.net) - XMLRPC. All YODA objectstore operations
such as get, set, drop_attr, drop add_class, drop_class are implemented
for XMLRPC. This valuable addition will allow users to create YODA
clients using almost any programming language (Java, C++, C, Perl and so
on. Of course, you can create XMLRPC clients using Python). This is open
door to using YODA in non-pythonic environments. As minor feature, YODA
now heavily depends on Pyro event service. It uses it for status
broadcasting and for sending notification to the servers in the YODA
network about node status.


       URL:  http://www.python.eu.org/software/database/Yoda/index_html
  Download:  http://sourceforge.net/project/showfiles.php?group_id=64535

   License:  Artistic
  Requires:  pybsddb3, Pyro, Ysvc, Yrnd, Yio, py-xmlrpc
  Binaries:  Linux

  Categories:  Net Applications, Databases

Vladimir Ulogov (gandalf@python.eu.org)
http://www.python.eu.org

--
<a href="http://www.python.eu.org/software/database/Yoda/index_html">YODA
distributed objectstore ver 1.1</a> -- Distributed objectstore with Pyro
and XMLRPC interfaces



From uche.ogbuji@fourthought.com  Tue Nov 19 16:20:23 2002
From: uche.ogbuji@fourthought.com (Uche Ogbuji)
Date: 19 Nov 2002 09:20:23 -0700
Subject: Article: RSS for Python
Message-ID: <mailman.1037732342.2440.clpa-moderators@python.org>

http://www-106.ibm.com/developerworks/webservices/library/ws-pyth11.html

RSS is one of the most successful XML services ever. Despite its chaotic
roots, it has become the community standard for exchanging content
information across Web sites. Python is an excellent tool for RSS
processing, and Mike Olson and Uche Ogbuji introduce a couple of modules
available for this purpose.

-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/py.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/index.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/index.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerworks/xml/library/x-tipgenr.html



From jjl@pobox.com  Tue Nov 19 19:12:39 2002
From: jjl@pobox.com (John J Lee)
Date: 19 Nov 2002 11:12:39 -0800
Subject: RELEASE: ClientForm 0.0.4b
Message-ID: <mailman.1037800444.28554.clpa-moderators@python.org>

ClientForm 0.0.4b

This is a beta release (probably the last before first stable release).

http://wwwsearch.sourceforge.net/ClientCookie/

Changes since the last release (0.0.3b):

 * Changed license to MIT (from Perl Artistic).  Thanks, Gisle.
   [MIT license essentially says: don't sue me.]
 * Various bug-fixes and documentation improvements.
 * Internal changes (internal unless you're using your own form parser):
   Control, ListControl and ScalarControl constructor cleanup, and
   separation of ListControl into RadioControl, CheckboxControl and
   SelectControl.
 * Rather than using the values of the OPTION elements to set SELECT
   values, SELECT items can also be specified by the labels of the
   OPTION elements.  For example, if you have a SELECT control like so:

   <SELECT name="cheeses">
     <OPTION value="br">Brie</OPTION>
     <OPTION value="ched">Cheddar</OPTION>
     <OPTION value="grgnz" label="Gorgonzola">Special offer on
       Gorgonzola!</OPTION>
   </SELECT>

   instead of setting its value like this:

   form["cheeses"] = ["br", "ched", "grgnz"]

   you can now optionally use the more readable (and, possibly, more
   maintainable):

   control = form.find_control("cheeses")
   control.set_value_by_label(["Brie", "Cheddar", "Gorgonzola"])

   Note that the label HTML attribute defaults to the content of the
   OPTION element (as does the value HTML attribute).


ClientForm is a Python module for handling HTML forms on the client
side, useful for parsing HTML forms, filling them in and returning the
completed forms to the server.  It has developed from a port of Gisle
Aas' Perl module HTML::Form, from the libwww-perl library, but the
interface is not the same.

 import ClientForm
 import urllib2
 request = urllib2.Request("http://www.acme.com/form.html")
 response = urllib2.urlopen(request)
 forms = ClientForm.ParseResponse(response)
 form = forms[0]
 form["cheeses"] = ["parmesan", "leicester", "cheddar"]
 form.toggle("cheeses", "gorgonzola")
 form["author"] = "Gisle Aas"
 request2 = form.click("Thanks")
 response2 = urllib2.urlopen(request2)

 print response2.geturl()
 print response2.info()  # headers
 for line in response2.readlines():  # body
     print line

All of the standard input types are supported: TEXT, PASSWORD, HIDDEN,
TEXTAREA, RESET, BUTTON, SUBMIT, IMAGE, RADIO, CHECKBOX and
SELECT/OPTION.  FILE (for file upload) is not yet supported, but will
be in a future version.

Python 1.5.2 or above is required.  To run the tests, you need the
unittest module (from PyUnit).  unittest is a standard library module
with Python 2.1 and above.


John


From jjl@pobox.com  Tue Nov 19 19:14:30 2002
From: jjl@pobox.com (John J Lee)
Date: 19 Nov 2002 11:14:30 -0800
Subject: RELEASE: ClientCookie 0.2.0b
Message-ID: <mailman.1037800445.28567.clpa-moderators@python.org>

ClientCookie 0.2.0b

This is a beta release (will be some time before I consider it stable,
but it's certainly quite useable as it is).

http://wwwsearch.sourceforge.net/ClientCookie/

Changes since the last release (0.1.2b):

 * Improved documentation.
 * Changed license to MIT (from Perl Artistic).  Thanks, Gisle.
   [MIT license essentially says: don't sue me.]
 * Removed cookies argument from urlopen, and added install_opener
   function.  This is the way urllib2 does things, and is also
   simpler.  This won't change again, honest!  The documentation on
   this is also much better now.
 * Removed _TimeLocal.py.  :-)

ClientCookie is a Python module for handling HTTP cookies on the
client side, useful for accessing web sites that require cookies to be
set, and returned later.  It is a port of Gisle Aas' Perl module
HTTP::Cookies, from the libwww-perl library.

 import ClientCookie
 response = ClientCookie.urlopen("http://foo.bar.com/")

This function behaves identically to urllib2.urlopen, except that it
deals with cookies automatically.  That's probably all you need to
know.

Python 1.5.2 or above is required.


Plans for the next few releases: non-eager response objects, while
retaining the seek method; HTTP-EQUIV and Refresh handling, via a new
OpenerDirector and Handler class(es).


John


From falted@openlc.org  Tue Nov 19 19:34:07 2002
From: falted@openlc.org (Francesc Alted)
Date: Tue, 19 Nov 2002 20:34:07 +0100
Subject: [ANN] PyTables release 0.2
Message-ID: <mailman.1037800446.28578.clpa-moderators@python.org>

Announcing PyTables 0.2
-----------------------

What's new
-----------

- Numerical Python arrays supported!
- Much improved documentation
- Programming API almost stable
- Improved navegability across the object tree
- Added more unit tests (there are almost 50)
- Dropped HDF5_HL dependency (a tailored version is included in sources now)
- License changed from LGPL to BSD

What is
-------

The goal of PyTables is to enable the end user to manipulate easily
scientific data tables and Numerical Python objects (new in 0.2!)  in
a persistent hierarchical structure. The foundation of the underlying
hierachical data organization is the excellent HDF5 library
(http://hdf.ncsa.uiuc.edu/HDF5). Right now, PyTables provides limited
support of all the HDF5 functions, but I hope to add the more
interesting ones (for PyTables needs) in the near future.
Nonetheless, this package is not intended to serve as a complete
wrapper for the entire HDF5 API.

A table is defined as a collection of records whose values are stored
in fixed-length fields. All records have the same structure and all
values in each field have the same data type.  The terms
"fixed-length" and strict "data types" seems to be quite a strange
requirement for an interpreted language like Python, but they serve a
useful function if the goal is to save very large quantities of data
(such as is generated by many scientifc applications, for example) in
an efficient manner that reduces demand on CPU time and I/O.

In order to emulate records (C structs in HDF5) in Python, PyTables
implements a special metaclass that detects errors in field
assignments as well as range overflows. PyTables also provides a
powerful interface to process table data.

Quite a bit effort has been invested to make browsing the hierarchical
data structure a pleasant experience. PyTables implements just three
(orthogonal) easy-to-use methods for browsing.

What is HDF5?
-------------

For those people who know nothing about HDF5, it is is a general
purpose library and file format for storing scientific data made at
NCSA. HDF5 can store two primary objects: datasets and groups. A
dataset is essentially a multidimensional array of data elements, and
a group is a structure for organizing objects in an HDF5 file. Using
these two basic constructs, one can create and store almost any kind of
scientific data structure, such as images, arrays of vectors, and
structured and unstructured grids. You can also mix and match them in
HDF5 files according to your needs.

How fast is it?
---------------

Despite to be an alpha version and that there is lot of room for
improvements (it's still CPU bounded!), PyTables can read and write
tables quite fast. But, if you want some (very preliminary) figures
(just to know orders of magnitude), in a AMD Athlon@900 it can
currently read from 40000 up to 60000 records/s and write from 5000 up
to 13000 records/s. Raw data speed in read mode ranges from 1 MB/s up
to 2 MB/s, and it drops to the 200 KB/s - 600 KB/s range for writes.

Go to http://pytables.sf.net/bench.html for a somewhat more detailed
description of this small (and synthetic) benchmark.

Anyway, this is only the beginning (premature optimization is the root
of all evils, you know ;-).

Platforms
---------

I'm using Linux as the main development platform, but PyTables should
be easy to compile/install on other UNIX machines. Thanks to Scott
Prater, this package has passed all the tests on a UltraSparc platform
with Solaris 7. It also compiles and passes all the tests on a SGI
Origin2000 with MIPS R12000 processors and running IRIX 6.5.

If you are using Windows and you get the library to work, please let
me know.

An example?
-----------

At the bottom of this message there is some code (less that 100 lines
and only less than half being real code) that shows basic capabilities
of PyTables.

Web site
--------

Go to the PyTables web site for more details:

http://pytables.sf.net/

Final note
----------

This is second alpha release, and probably last alpha, so it is
still time if you want to suggest some API addition/change or
addition/change of any useful missing capability. Let me know of any
bugs, suggestions, gripes, kudos, etc. you may have.

-- Francesc Alted
falted@openlc.org


*-*-*-**-*-*-**-*-*-**-*-*- Small code example  *-*-*-**-*-*-**-*-*-**-*-*-*

"""Small but almost complete example showing the PyTables mode of use.

As a result of execution, a 'tutorial1.h5' file is created. You can
look at it with whatever HDF5 generic utility, like h5ls, h5dump or
h5view.

"""


import sys
from Numeric import *
from tables import *


	#'-**-**-**-**-**-**- user record definition  -**-**-**-**-**-**-**-'

# Define a user record to characterize some kind of particles
class Particle(IsRecord):
    name        = '16s'  # 16-character String
    idnumber    = 'Q'    # unsigned long long (i.e. 64-bit integer)
    TDCcount    = 'B'    # unsigned byte
    ADCcount    = 'H'    # unsigned short integer
    grid_i      = 'i'    # integer
    grid_j      = 'i'    # integer
    pressure    = 'f'    # float  (single-precision)
    energy      = 'd'    # double (double-precision)

print
print	'-**-**-**-**-**-**- file creation  -**-**-**-**-**-**-**-'

# The name of our HDF5 filename
filename = "tutorial1.h5"
    
print "Creating file:", filename

# Open a file in "w"rite mode
h5file = openFile(filename, mode = "w", title = "Test file")

print
print	'-**-**-**-**-**-**- group an table creation  -**-**-**-**-**-**-**-'

# Create a new group under "/" (root)
group = h5file.createGroup("/", 'detector', 'Detector information')
print "Group '/detector' created"

# Create one table on it
table = h5file.createTable(group, 'readout', Particle(), "Readout example")
print "Table '/detector/readout' created"

# Get a shortcut to the record object in table
particle = table.record

# Fill the table with 10 particles
for i in xrange(10):
    # First, assign the values to the Particle record
    particle.name  = 'Particle: %6d' % (i)
    particle.TDCcount = i % 256    
    particle.ADCcount = (i * 256) % (1 << 16)
    particle.grid_i = i 
    particle.grid_j = 10 - i
    particle.pressure = float(i*i)
    particle.energy = float(particle.pressure ** 4)
    particle.idnumber = i * (2 ** 34)  # This exceeds long integer range
    # Insert a new particle record
    table.appendAsRecord(particle)      

# Flush the buffers for table
table.flush()

print
print	'-**-**-**-**-**-**- table data reading & selection  -**-**-**-**-**-'

# Read actual data from table. We are interested in collecting pressure values
# on entries where TDCcount field is greater than 3 and pressure less than 50
pressure = [ x.pressure for x in table.readAsRecords()
	         if x.TDCcount > 3 and x.pressure < 50 ]
print "Last record read:"
print x
print "Field pressure elements satisfying the cuts ==>", pressure

# Read also the names with the same cuts
names = [ x.name for x in table.readAsRecords()
	      if x.TDCcount > 3 and x.pressure < 50 ]

print
print	'-**-**-**-**-**-**- array object creation  -**-**-**-**-**-**-**-'

print "Creating a new group called '/columns' to hold new arrays"
gcolumns = h5file.createGroup(h5file.root, "columns", "Pressure and Name")

print "Creating a Numeric array called 'pressure' under '/columns' group"
h5file.createArray(gcolumns, 'pressure', array(pressure), 
                   "Pressure column selection")

print "Creating another Numeric array called 'name' under '/columns' group"
h5file.createArray('/columns', 'name', array(names),
                   "Name column selection")

# Close the file
h5file.close()
print "File '"+filename+"' created"



From chrisw@nipltd.com  Tue Nov 19 20:32:16 2002
From: chrisw@nipltd.com (Chris Withers)
Date: Tue, 19 Nov 2002 20:32:16 +0000
Subject: Strip-o-Gram 1.2 Released!
Message-ID: <mailman.1037800447.28590.clpa-moderators@python.org>

Strip-o-Gram is an HTML Conversion Library implemented as a Python package that 
can convert HTML to Plain Text and strip specified tags and Javascript from HTML.

See http://www.zope.org/Members/chrisw/StripOGram for more details.

This release includes more documentation and allows the methods to be used from 
Zope's Script (Python)'s.

cheers,

Chris



From djc@object-craft.com.au  Wed Nov 20 01:25:48 2002
From: djc@object-craft.com.au (Dave Cole)
Date: 20 Nov 2002 12:25:48 +1100
Subject: Sybase module 0.35 released
Message-ID: <mailman.1037800449.28606.clpa-moderators@python.org>

WHAT IS IT:

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

NOTES:

In this release the module uses callback instead of inline error
handling from the Sybase CT library.  This has caused quite extensive
changes to the threading support inside the low level extension
module.

One of the nice side effects of using callback error handling is that
server errors while executing stored procedures will now be reported
correctly.

FreeTDS support is much improved in this version.

You can build for FreeTDS like this:

     python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY
     python setup.py install

The module is available here:

    http://www.object-craft.com.au/projects/sybase/download/sybase-0.35.tar.gz

The module home page is here:

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

CHANGES SINCE 0.35pre3:

No problems were reported with the 0.35pre3 release so the changes are
minimal.

* sybasect extension module now includes a __version__ string.

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



From djc@object-craft.com.au  Wed Nov 20 03:31:28 2002
From: djc@object-craft.com.au (Dave Cole)
Date: 20 Nov 2002 14:31:28 +1100
Subject: csv module 1.0 released
Message-ID: <mailman.1037800451.28620.clpa-moderators@python.org>

WHAT IS IT:

The CSV module provides a fast CSV parser which can split and join CSV
records which have been produced by Microsoft products such as Access
and Excel.

The module is available here:

    http://www.object-craft.com.au/projects/csv/download/csv-1.0.tar.gz

The module home page is here:

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

NOTES:

The most important change for this release is that the basic quote
handling has been modified to exactly match the observed behaviour of
Excel.  A comprehensive test suite has been added to test this
observed behaviour.  If the module does not conform to Excel behaviour
we consider this to be a bug.

No problems were reported with the 1.0pre1 release.  This release
makes the 1.0pre1 release official.

CHANGES SINCE 0.5:

* Moved to standard BSD template license.

* Now using distutils to create source distribution.

* Parser's handling of unusual quoting styles was found to be at odds
  with Excel. In particular, Excel only treats the quote character as
  special if it appears as the first character in a field, whereas our
  parser honoured them anywhere. We now produce the same result as Excel -
  quotes within a field appear in the output.

* Introduced Parser.quote_char attribute to replace the hard coded "
  (double quote).  You can now disable quoting by setting quote_char
  to 0 or None.

* Introduced Parser.escape_char attribute which is used to escape
  special characters when quote_char is specified is disabled.

* Introduced Parser.strict attribute which controls whether the parser
  will raise an exception on malformed fields rather than attempting
  to guess the right behaviour.

* Introduced a suite of unit tests.

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



From jgoerzen@complete.org  Wed Nov 20 16:12:51 2002
From: jgoerzen@complete.org (John Goerzen)
Date: Wed, 20 Nov 2002 16:12:51 +0000 (UTC)
Subject: Pyme -- Python OO interface to GPGME
Message-ID: <mailman.1037884084.2492.clpa-moderators@python.org>

Hello,

Today I am announcing the first release of Pyme, the brand-new Python
bindings for GPGME.  Pyme:

 * Provides a convenient class-based interface to GPGME functions;
 * Exists and is supported;
 * Supports most GPGME functions automatically by reflection; thus,
   no code changes will be necessary to support most new GPGME features
 * Supports callbacks written in Python.
 * Features easy installation:  python setup.py build; python setup.py install
 * Provides pre-built .debs for Debian GNU/Linux users.

You may obtain Pyme at http://quux.org/devel/pyme
License: GPL

The following is from the Pyme documentation:

Welcome to PyME, the GPGME Interface for Python.  "Pyme", when prounced,
rhymes with "Pine".

The latest release of this package may be obtained from
http://quux.org/devel/pyme/

FEATURES
--------

 * Feature-rich, full implementation of the GPGME library.  Supports
   all GPGME features except interactive editing (coming soon).
   Callback functions may be written in pure Python.

 * Ability to sign, encrypt, decrypt, and verify data.

 * Ability to list keys, export and import keys, and manage the keyring.

 * Fully object-oriented with convenient classes and modules.

GENERAL OVERVIEW
----------------

For those of you familiar with GPGME, you will be right at home here.

Pyme is, for the most part, a direct interface to the C GPGME
library.  However, it is re-packaged in a more Pythonic way --
object-oriented with classes and modules.  Take a look at the classes
defined here -- they correspond directly to certain object types in GPGME
for C.  For instance, the following C code:

GpgmeCtx context;
GpgmeRecipients recp;
gpgme_new(&context);
gpgme_recipients_new(&recp);
...
gpgme_op_encrypt(context, recp, plain, cipher);

Translates into the following Python code:

context = core.Context()
recp = core.Recipients()
...
context.encrypt(recp, plain, cipher)

The Python module automatically does error-checking and raises Python
exceptions when GPGME signals an error.  Those exceptions correspond
directly to GPGME errors.  All GPGME exceptions are defined in the
gpgme.errors module, and pyme.errors.GPGMEError is the parent of all
exceptions.

IMPORTANT NOTE
--------------
This documentation only covers a small subset of available GPGME functions and
methods.  Please consult the documentation for the C library
(available in doc/gpgme in this distribution) for comprehensive coverage.

This library uses Python's reflection to automatically detect the methods
that are available for each class, and as such, most of those methods
do not appear explicitly anywhere.

QUICK START SAMPLE PROGRAM
--------------------------
This program is not for serious encryption, but for example purposes only!

import sys
from pyme import core, constants
import pyme.constants.validity

# Set up our input and output buffers.

plain = core.Data('This is my message.')
cipher = core.Data()

# Initialize our context.

c = core.Context()
c.set_armor(1)

# Set up the recipients.

sys.stdout.write("Enter name of your recipient: ")
name = sys.stdin.readline().strip()
r = core.Recipients()
r.add(name, constants.validity.FULL)

# Do the encryption.

c.op_encrypt(r, plain, cipher)
print cipher.read()

Note that although there is no explicit error checking done here, the
Python GPGME library is automatically doing error-checking, and will
raise an exception if there is any problem.

This program is in the Pyme distribution as examples/simple.py.  The examples
directory contains more advanced samples as well.

FOR MORE INFORMATION
--------------------
PYME homepage: http://quux.org/devel/pyme
GPGME documentation: http://www.fifi.org/cgi-bin/info2www?%28gpgme%29
GPGME homepage: http://www.gnupg.org/gpgme.html

Base classes: pyme.core (START HERE!)
Auxiliary classes: pyme.aux
Utilities: pyme.util
Error classes: pyme.errors
Constants: pyme.constants
Version information: pyme.version

Base classes are documented at pyme.core and auxiliary classes at pyme.aux

<P><A HREF="http://quux.org/devel/pyme">Pyme 0.5.0</A> -- OO Python
interface to GnuPG.  (20-Nov-02)


From wesc@deirdre.org  Thu Nov 21 08:41:30 2002
From: wesc@deirdre.org (wesc@deirdre.org)
Date: Thu, 21 Nov 2002 00:41:30 -0800 (PST)
Subject: ANN: Python Programming course (Silicon Valley, CA)
Message-ID: <mailman.1037884084.2493.clpa-moderators@python.org>

"Python Programming" course
UC Santa Cruz, Winter Quarter 2002
Jan 6 - Mar 10, 2003 (except Jan 20 and Feb 17)
Monday nights, 6:30 - 9:30pm
Sunnyvale, California

http://artemis.ucsc-extension.edu/~wesc/013e44cd.htm

Register online, or contact Sherry at 408-861-3765 or
smirkarimi@ucsc-extension.edu to enroll.  Sign up soon!
Early registration deadline is December 20, 2002.
Hope to see some of you there!

I will be giving a Python Programming 2 course which
follows this one in the Spring.  Alternatively, an
introduction to programming course using Python will
also be offered this Winter with another instructor
-- ask Sherry for more details.

-wesley

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

"Core Python Programming", Prentice Hall PTR, © 2001
    http://starship.python.net/crew/wesc/cpp/

Silicon Valley-San Francisco Bay Area Python Users Group (BayPIGgies)
    http://www.baypiggies.net

wesley.j.chun :: wesc at deirdre.org
cyberweb.consulting : henderson, nv : cyberweb at rocketmail.com
http://roadkill.com/~wesc/cyberweb/


From max@alcyone.com  Fri Nov 22 01:47:18 2002
From: max@alcyone.com (Erik Max Francis)
Date: Thu, 21 Nov 2002 17:47:18 -0800
Subject: ANN: empy 2.2 -- A templating system for Python
Message-ID: <mailman.1037999043.12705.clpa-moderators@python.org>

Summary

    A templating system for Python.


Overview

    empy is a system for embedding Python expressions and statements
    in template text; it takes an empy source file, processes it, and
    produces output.  This is accomplished via expansions, which are
    special signals to the empy system and are set off by a special
    prefix (by default the at sign, '@').  empy can expand arbitrary
    Python expressions and statements in this way, as well as a
    variety of special forms.  Textual data not explicitly delimited
    in this way is sent unaffected to the output, allowing Python to
    be used in effect as a markup language.  Also supported are "hook"
    callbacks, recording and playback via diversions, and dynamic,
    chainable filters.  The system is highly configurable via command
    line options and embedded commands.

    Expressions are embedded in text with the '@(...)' notation;
    variations include conditional expressions with '@(...?...:...)'
    and the ability to handle thrown exceptions with '@(...$...)'.  As
    a shortcut, simple variables and expressions can be abbreviated as
    '@variable', '@object.attribute', '@function(arguments)',
    '@sequence[index]', and combinations.  Full-fledged statements
    are embedded with '@{...}'.  Forms of conditional, repeated, and
    recallable expansion are available via '@[...]'.  A '@' followed
    by a whitespace character (including a newline) expands to
    nothing, allowing string concatenations and line continuations.
    Comments are indicated with '@#' and consume the rest of the line,
    up to and including the trailing newline.  '@%' indicate
    "significators," which are special forms of variable assignment
    intended to specify per-file identification information in a
    format which is easy to parse externally.  Escape sequences
    analogous to those in C can be specified with '@\...', and finally
    a '@@' sequence expands to a single literal at sign.


Getting the software

    The current version of empy is 2.2.

    The latest version of the software is available in a tarball here:
    http://www.alcyone.com/pyos/empy/empy-latest.tar.gz.

    The official URL for this Web site is
    http://www.alcyone.com/pyos/empy/.


Requirements

    empy should work with any version of Python from 1.5.x onward.
    The test script is intended to run on UNIX-like systems with a
    Bourne shell.


License

    This code is released under the GPL.

	...


Release history [since 2.1]

    - 2.2; 2002 Nov 21.  Switched to -V option for version
      information; 'empy.createDiversion' for creating initially empty
      diversion; direct access to diversion objects with
      'empy.retrieveDiversion'; environment variable support; removed
      --raw (used --raw-errors instead) long argument; added
      quaternary escape code (well, why not).

-- 
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ If a thing is worth doing, then it is worth doing badly.
\__/ G.K. Chesterton
    REALpolitik / http://www.realpolitik.com/
 Get your own customized newsfeed online in realtime ... for free!


From gbugmann@soc.plym.ac.uk  Fri Nov 22 10:43:33 2002
From: gbugmann@soc.plym.ac.uk (Guido.Bugmann xtn 2566)
Date: Fri, 22 Nov 2002 10:43:33 +0000 (GMT)
Subject: Brill tagger and Abney parser dll modules available
Message-ID: <mailman.1037999043.12712.clpa-moderators@python.org>

Hello,

Python modules are now available for the Brill tagger and
the Abney parser. 

http://www.tech.plym.ac.uk/soc/staff/guidbugm/pysoftware.htm

They have been compiled using Swig 1.1-883 under VC++4.0. 

Only the essential functions of the above softwares have
been implemented.

Sample Python programs using the modules are available. 
The programs have been tested under Python 1.52 on a
WIN98 machine.

The original distributions of the Brill tagger and the Abney Parser 
are also available from the above web site.

Best regards
Guido

 -----------------------------
 Dr. Guido Bugmann
 Senior Research Fellow
 Centre for Neural and Adaptive Systems
 School of Computing
 University of Plymouth
 Plymouth PL4 8AA
 United Kingdom
 -----------------------------

 Tel: (+44) 1752 23 25 66 / 41
 Fax: (+44) 1752 23 25 40
 Email: gbugmann@soc.plymouth.ac.uk
 or gbugmann@plymouth.ac.uk
 http://www.tech.plym.ac.uk/soc/Staff/GuidBugm/Bugmann.htm
 -----------------------------



From Rimon Barr <barr@CS.Cornell.EDU>  Fri Nov 22 20:43:53 2002
From: Rimon Barr <barr@CS.Cornell.EDU> (Rimon Barr)
Date: Fri, 22 Nov 2002 15:43:53 -0500 (EST)
Subject: spyce v1.2.9 released
Message-ID: <mailman.1037999044.12716.clpa-moderators@python.org>

Spyce v1.2.9 released on 22 Nov 2002

SPYCE is a server-side engine that supports simple and efficient
Python-based dynamic HTML generation. Those who like Python and are
familiar with JSP, or PHP, or ASP, should have a look at this engine. It
allows one to generate dynamic HTML content just as easily, using Python
for the dynamic parts. Its modular design makes it very flexible and
extensible. It can also be used as a command-line utility for HTML
pre-processing.

Get it at:
  http://spyce.sourceforge.net

This release includes lots of outstanding feature requests:
  - lots of updates to the stdout, session, response and spylambda modules
      (see change log)
  - capturing output and memoized spylambda execution

Enjoy,
Rimon.
---
Partial Change Log:

v1.2.9
  stdout.push() can now accept no file argument
  stdout.pop() now returns captured output
  stdout.capture() added
    see: examples/stdout.spy and stdout module docs
  session_user session handler added in session module
    see: examples/mysession.spy and session module docs
  spylambda.define() can now memoize
    see: http://spyce.sourceforge.net/doc-mod_lambda.html
  memoized spyce lambda syntax: [[spy! ...: ...]]
    see: http://spyce.sourceforge.net/doc-lang_lambda.html
  slight modification to spyce.vim syntax file
  response.addHeader() now support replacement
  response.timestamp(), expire(), expireRel(), lastModified()
      and uncacheable() methods added
    see: http://spyce.sourceforge.net/doc-mod_response.html
  performance!

v1.2.8
  links page added
  spyce VIM syntax file updated; deals with spyce lambdas
  include module improvements
  - 'vars' field added
  - included file can return value
  - documentation updated, specifically regarding use of 'context'

...



From max@alcyone.com  Sat Nov 23 12:30:20 2002
From: max@alcyone.com (Erik Max Francis)
Date: Sat, 23 Nov 2002 04:30:20 -0800
Subject: ANN: CSBuddy 1.2 -- A Counter-Strike server file log file monitor and
 administration
 tool
Message-ID: <mailman.1038234112.29032.clpa-moderators@python.org>

Summary

    CSBuddy is a tool designed to help Counter-Strike server owners,
    particularly those running AdminMod.  It does two things: First,
    it maintains a queryable database of all players that have been
    seen on the server; and second, it filters the raw logs of a
    Counter-Strike server and distills them into a single CSBuddy log
    which shows only high-level activity such as excessive friendly
    fire incidents, admin activity, and players complaining about
    misbehavior or saying suspicious things.

    This tool is built upon an included Counter-Strike log file parser
    which is provided in a simple derivable class.


Getting the software

    The current version of csbuddy is 1.2.

    The latest version of the software is available in a tarball here:
    http://www.alcyone.com/pyos/csbuddy/csbuddy-latest.tar.gz.

    The official URL for this Web site is
    http://www.alcyone.com/pyos/csbuddy/.


Requirements

    CSBuddy requires Python version 2.0 or greater.


License

    This code is released under the GPL.

	...


Release history [since 1.0]

    - 1.2; 2002 Nov 23.  Add -J option for finding by IP prefix
      (subnet); default data files directory changed to
      $HOME/.csbuddy instead of $HOME; improved invocation reference
      in documentation.

    - 1.1; 2002 Nov 10.  Convert commands to lowercase before
      checking; add -b option for brief reporting; add -P option for
      checking case insensitive substrings; use -V option for version
      information.

    - 1.0.3; 2002 Oct 14.  Bugfix:  Regular expression dictionary had
      ambiguous cases which showed up in later versions of Python
      (punish commands not appearing properly).

    - 1.0.2; 2002 Oct 10.  Support for kick and secure kick messages;
      save csbuddy.state file as binary to improve performance.

    - 1.0.1; 2002 Aug 27.  Minor bugfix:  Normal say events were not
      being reported in the .chat log file.

-- 
 Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ Love, the itch, and a cough cannot be hid.
\__/ Thomas Fuller, M.D.
    CAGE / http://www.alcyone.com/pyos/cage/
 A cellular automaton simulation system in Python.


From pinard@iro.umontreal.ca  Sun Nov 24 02:37:46 2002
From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois?= Pinard)
Date: 23 Nov 2002 21:37:46 -0500
Subject: RELEASED: Pymacs 0.20
Message-ID: <mailman.1038234113.29056.clpa-moderators@python.org>

Hello to everybody, and especially to Emacs users among Python lovers.

The day after Pymacs 0.19 was released, I found that Pymacs interferes with
the Emacs interactive documentation system.  Despite the problem shows only
in unusual circumstances -- adviced functions, functions using a mere symbol
for their body -- I do not want that bug in released Pymacs.  I waited a bit
just in case some other bug shows.  After one week, since none want to get
out, better have another release out now.  So here it is!  :-)

--------------------

Pymacs is a powerful tool which, once started from Emacs, allows both-way
communication between Emacs Lisp and Python.  Pymacs aims Python as an
extension language for Emacs rather than the other way around, and this
assymetry is reflected in some design choices.  Within Emacs Lisp code, one
may load and use Python modules.  Python functions may themselves use Emacs
services, and handle Emacs Lisp objects kept in Emacs Lisp space.

`http://www.iro.umontreal.ca/~pinard/pymacs/' contains a copy of the
Pymacs documentation in HTML form.  The canonical Pymacs distribution is
available as `http://www.iro.umontreal.ca/~pinard/pymacs/Pymacs.tar.gz'.
Report problems and suggestions to `mailto:pinard@iro.umontreal.ca'.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard


From detlev@die-offenbachs.de  Sun Nov 24 09:51:55 2002
From: detlev@die-offenbachs.de (Detlev Offenbach)
Date: Sun, 24 Nov 2002 10:51:55 +0100
Subject: ANN: Eric 3.0.0-alpha1 released
Message-ID: <mailman.1038234114.29077.clpa-moderators@python.org>

Hi,

Eric 3.0.0-alpha1 is available for download via

http://www.die-offenbachs.de/detlev/eric3.html

What is it?
-----------
Eric 3.0.0 (or short eric3) is a Python IDE written using PyQt and 
QScintilla. It has integrated project management capabilities, it gives 
you an unlimited number of editors, an integrated Python shell, an 
integrated debugger and more.

Please see for yourself by visiting the a.m. page (it contains a picture 
of Eric our mascot as well).

Please report bugs, feature wishes or code contributions to 
eric-bugs@die-offenbachs.de

Help wanted!!
-------------
I would need some support in the area of more translations and user 
documentation. Any volunteers out there? Just let me know.

Regards,
Detlev
-- 
Detlev Offenbach
detlev@die-offenbachs.de



From detlev@die-offenbachs.de  Sun Nov 24 16:22:30 2002
From: detlev@die-offenbachs.de (Detlev Offenbach)
Date: Sun, 24 Nov 2002 17:22:30 +0100
Subject: ANN: Eric 3.0.0-alpha2 released
Message-ID: <mailman.1038234115.29092.clpa-moderators@python.org>

Hi,

Eric 3.0.0-alpha2 is available for download via

http://www.die-offenbachs.de/detlev/eric3.html

What is it?
-----------
Eric 3.0.0 (or short eric3) is a Python IDE written using PyQt and 
QScintilla. It has integrated project management capabilities, it gives 
you an unlimited number of editors, an integrated Python shell, an 
integrated debugger and more.

Please see for yourself by visiting the a.m. page (it contains a picture 
of Eric our mascot as well).

Please report bugs, feature wishes or code contributions to 
eric-bugs@die-offenbachs.de

Help wanted!!
-------------
I would need some support in the area of more translations and user 
documentation. Any volunteers out there? Just let me know.

Regards,
Detlev
-- 
Detlev Offenbach
detlev@die-offenbachs.de


From j-david@noos.fr  Sun Nov 24 17:29:49 2002
From: j-david@noos.fr (=?ISO-8859-1?Q?Juan_David_Ib=E1=F1ez_Palomar?=)
Date: Sun, 24 Nov 2002 18:29:49 +0100
Subject: flux 0.2 released
Message-ID: <mailman.1038234116.29109.clpa-moderators@python.org>

This is a multi-part message in MIME format.
--------------010900090809010400020902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


flux is a python module that helps to implement workflow based
applications. The 0.2 release has a new and much improved API,
the complete changelog is attached. This version is the work
of Thilo Ernst, thanks Thilo!

Download from http://sourceforge.net/projects/lleu


Best regards,

-- 
J. David Ibáñez, http://www.j-david.net
Software Engineer / Ingénieur Logiciel / Ingeniero de Software


--------------010900090809010400020902
Content-Type: text/plain;
 name="CHANGES.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="CHANGES.txt"

0.2.0

- introduced leave-state handlers flux_onleave_stateXYZ,
- renamed enter-state handlers flux_stateXYZ -> flux_onenter_stateXYZ
- introduced natural handler invocation order:
  leave-state handler for old state, transition handler, 
  enter-state handler for new state
- made enter-state handler be called from  WorkflowAware.flux_workflow_set

- introduced optional extra arguments to WorkflowAware.flux_transition,
  WorkflowAware.flux_workflow_set which are passed through to all handlers
- renamed WorkflowAware.flux_workflow_set -> flux_workflow_enter
- changed interpretation of workflow's initial state to be just 
  the "default initial state" and made it entirely optional
- introduced optional 2nd argument 'initstate' to 
  WorkflowAware.flux_workflow_enter: explicit overiding initial state 
  to be entered - if absent or None, workflow must provide default
  
- introduced module-specific exception FluxError
- introduced checks to catch mistyped state/transition names early
  and with sensible error messages: raise FluxError on attempts 
  to access nonexisting states (in Workflow.flux_trasition_add) or 
  transitions (in WorkflowAware.flux_transition)
- introduced checks for  undefined/invalid initial state in 
  WorkflowAware.flux_workflow_enter
  
- Switched to new naming scheme:
  * 'fx_' as shorter general flux prefix
  * predefined method names look like this:     
    fx_<actionpart>
    e.g. fx_addstate
  * semi-predefined method names look like this:  
    fx_<actionpart>_<userdef_part>
    e.g. fx_ontrans_publish   # where 'publish' is a transition name
    (idea: second _ indicates what follows is a userdef name component)
  * action_part is either <verb><noun> or <preposition><noun>
- introduced WorkflowAware.fx_getstate() method (inspect current state)
- updated/extended method docstrings

--------------010900090809010400020902--



From itamar@itamarst.org  Mon Nov 25 17:44:29 2002
From: itamar@itamarst.org (Itamar Shtull-Trauring)
Date: Mon, 25 Nov 2002 12:44:29 -0500
Subject: ANN: Twisted 1.0.1, the Framework of Your Internet
Message-ID: <mailman.1038322803.8093.clpa-moderators@python.org>

Twisted is an event-driven networking framework for server and client
applications.

For more information, visit http://www.twistedmatrix.com, join the list
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python or
visit us on #twisted at irc.freenode.net (also known as
irc.openprojects.net).


What's New in 1.0.1
===================

 - Lore, a documentation generation framework supporting HTML and LaTeX
 - Initial SOAP support
 - Rewritten UDP API
 - Multicast support
 - Better Tk integration
 - Rewritten DNS protocol, both client and server
 - Virtual hosting utilities for twisted.web
 - Large amounts of work on Woven web templating system
 - Syslog logging
 - GUI equivalents of the command-line mktap and twistd programs
 - Much improved and expanded documentation
 - Many bugfixes


What is Twisted?
================

Twisted is an event-driven framework for building networked clients and
servers.  It contains a powerful and simple networking core, a
full-featured suite of interoperable protocols, among them a powerful
web server and applications framework.

Twisted supports many event loops for both server apps and GUI
integration on the client side, including:

 - select()
 - poll()
 - kqueue on FreeBSD
 - Win32 events, including GUI support
 - GTK+
 - Qt
 - wxPython
 - Tkinter
 - Java

Twisted can run protocols over TCP, SSL, Unix sockets and subprocesses.
It also includes scheduling support, threading integration, RDBMS event
loop integration and other basic requirements for networked
applications.

Also included are implementations of many protocols. In some cases this
includes complete frameworks providing facilities on top of the base
protocol:

 - SSH
 - FTP
 - HTTP, including a complete web framework
 - XML-RPC server framework
 - SOAP server framework
 - NNTP and complete NNTP server framework
 - SOCKSv4 (server only)
 - SMTP
 - IRC
 - telnet
 - POP3
 - AOL's instant messaging TOC
 - OSCAR, used by AOL-IM as well as ICQ (client only)
 - DNS
 - MouseMan serial mice
 - Twisted Perspective Broker, a remote object protocol


From edream@tds.net  Mon Nov 25 15:46:02 2002
From: edream@tds.net (Edward K. Ream)
Date: Mon, 25 Nov 2002 15:46:02 GMT
Subject: ANN: Leo 3.9 outlining editor
Message-ID: <mailman.1038322802.8036.clpa-moderators@python.org>

leo.py 3.9 is now available at:  http://sourceforge.net/projects/leo/
leo.py requires Python 2.1 or above and tcl/tk 8.3 or above.

This is one of the most interesting versions of Leo ever released:

The highlights of 3.9:
----------------------
* Major performance improvements:
  - Incremental syntax coloring speeds response when typing.
  - Incremental undo drastically reduces memory used.

* Major improvements in customizing Leo:
  - Leo looks in the file customizeLeo.py for user-specific customizations.
  - Leo calls "hook routines" in customizeLeo.py for all commands and
events.
    These hook routines can modify or replace any command or event.
  - New convenience routines simplify creating and modifying menus.
  - Easy translation of menus to other languages using customizeLeo.py.

* Better integration with other tools:
  - The Open With command allows you to communicate back and forth with
other editors.
  - The Go To Line Number command converts lines numbers in derived files
    to locations in the outline.
  - Double-clicking the icon of a @url node launches any url in your web
browser.
  - The Execute Script command executes Python code in any body pane.
    This is much more convenient than opening Leo's Idle window.
  - Much better support for cweb. At last, Leo has a power user of cweb.
    By default, @space, @* and @** sections are colored as latex text.
    Leo properly generates @q..@> sentinels.
  - @nosentinelfile is like @file except Leo writes no sentinel lines.

* Other improvements:
  - Optional Emacs-style auto-indent.
  - Reformat Paragraph command.
  - Leo will optionally create nonexistent directories specified in
    @file, @root or @path, including all nonexistent parent directories.
  - Leo will place its own icon in Leo windows provided that you have
    installed Fredrik Lundh's PIL and tkIcon packages.
  - The usual assortment of bug fixes.

Quote of the month:
-------------------
"When first I opened Leo, it was out of curiosity. But having used it...
I'LL NEVER GO BACK. THEY'LL HAVE TO PRY LEO OUT OF MY COLD, DEAD FINGERS!
Seriously,it should be renamed 'Crack Cocaine' because it's that addictive.
I'm ready to start a 12-Step group." -- Travers A. Hough

What is Leo?
------------
 - A programmer's editor, an outlining editor and a flexible browser.
 - A literate programming tool, compatible with noweb and CWEB.
 - A data organizer and project manager. Leo provides multiple views
   of projects within a single outline.
 - Fully scriptable using Python. Leo saves its files in XML format.
 - Portable. leo.py is 100% pure Python.
 - Open Software, distributed under the Python License.

Links:
------
Leo:      http://personalpages.tds.net/~edream/front.html
Home:     http://sourceforge.net/projects/leo/
Download: http://sourceforge.net/project/showfiles.php?group_id=3458
CVS:      http://sourceforge.net/cvs/?group_id=3458

--------------------------------------------------------------------
Edward K. Ream   email:  edream@tds.net
Leo: Literate Editor with Outlines
Leo: http://personalpages.tds.net/~edream/front.html
--------------------------------------------------------------------



From Rimon Barr <barr@CS.Cornell.EDU>  Tue Nov 26 01:08:12 2002
From: Rimon Barr <barr@CS.Cornell.EDU> (Rimon Barr)
Date: Mon, 25 Nov 2002 20:08:12 -0500 (EST)
Subject: spyce v1.3.0 released
Message-ID: <mailman.1038322803.8134.clpa-moderators@python.org>

Spyce v1.3.0 released on 25 Nov 2002

SPYCE is a server-side engine that supports simple and efficient
Python-based dynamic HTML generation. Those who like Python and are
familiar with JSP, or PHP, or ASP, should have a look at this engine. It
allows one to generate dynamic HTML content just as easily, using Python
for the dynamic parts. Its modular design makes it very flexible and
extensible. It can also be used as a command-line utility for HTML
pre-processing.

Get it at:
  http://spyce.sourceforge.net

A major release with a new language feature: active tags.
  see: http://spyce.sourceforge.net/doc-tag.html
  Please refer to the change-log below.

Enjoy,
Rimon.

---
Partial Change Log:

v1.3.0
  active tags introduced
    - see: http://spyce.sourceforge.net/doc-tag.html
    - [[.taglib]] directive added
    - taglib spyce module added
    - compiler changes to deal with active tags
    - tagging infrastructure (spyceTag, spyceTagPlus, spyceTagLibrary)
        - see: spyceTags.py
        - user-defined active tag libraries possible
        - see: http://spyce.sourceforge.net/doc-tag_new.html
    - core active tag library
        see: tags/core.py
        see: http://spyce.sourceforge.net/doc-tag_core.html
    - tag libraries loaded from same path as modules
    - compiler syntax checking improved
      - check for unbalanced parens
      - check for unbalanced active tags
      - extensible syntax checking for active tags

v1.2.10
  bugfix - typo in spyceWWW caused threading mode startup failure



From webadministrator@ozzope.org  Tue Nov 26 23:05:45 2002
From: webadministrator@ozzope.org (Jan Smith)
Date: Wed, 27 Nov 2002 10:05:45 +1100
Subject: Where is Python being taught in Australia?
Message-ID: <mailman.1038864723.23752.clpa-moderators@python.org>

Hi all,

I am compiling of list of institutions teaching Python for the OzZope web
site - the Australian Zope Interest Group.  It would be great to have an up
to date list.

Sometimes the subject is not specifically python but python is taught as
part a course.  Any course including python is what I'm looking for.

Also any places that may be teaching Zope.

Reply to.  mailto:webadministrator@ozzope.org

Many thanks


Jan Smith
Web Administrator
www.ozzope.org
Australian Zope Interest Group



From mwarden22@hotmail.com  Tue Nov 26 23:29:12 2002
From: mwarden22@hotmail.com (nealj)
Date: 26 Nov 2002 15:29:12 -0800
Subject: ANN: Hap Debugger 3.0 released
Message-ID: <mailman.1038864724.23764.clpa-moderators@python.org>

A new version of the Hap python debugger has just been released on sourceforge.  

<http://sourceforge.net/projects/hapdebugger>

This release adds a number of improvements and new features:
-Correct exception handling
-Improved debugging capabilities
-Python line count tracking (for python optimization)
-ctags support
-improved project file format
-watch tooltips (hover over self at a breakpoint)


From peter@engcorp.com  Wed Nov 27 04:15:38 2002
From: peter@engcorp.com (Peter Hansen)
Date: Tue, 26 Nov 2002 23:15:38 -0500
Subject: PyGTA Announcement: next meeting is Thursday December 12, 8-10 pm
Message-ID: <mailman.1038864725.23780.clpa-moderators@python.org>

I'm pleased to announce that next meeting of PyGTA, the Toronto-area 
Python and Zope user group, will be on Thursday December 12.

It will be held at the 519 Church St. Community Centre,
near Wellesley, from 8 to 10 p.m.  This is the same location
as last time.

Please visit http://web.engcorp.com/pygta/wiki/NextMeeting
for other details of the meeting, as usual.  As usual we're extending 
an invitation to you to come and present for 5-10 minutes on your own 
Python activity if you believe it will be of interest to others...
just let us know ahead of time so we can leave time for it.

In addition, note our new Mailman-based mailing lists, described
at http://web.engcorp.com/pygta/wiki/MailingLists .  The old
announcement list has been replaced, and there is a general list
for group discussion purposes as well.

-Ian Garmaise and
 Peter Hansen,
 PyGTA organizers


From Marc.Poinot@onera.fr  Fri Nov 29 08:16:40 2002
From: Marc.Poinot@onera.fr (Marc Poinot)
Date: Fri, 29 Nov 2002 09:16:40 +0100
Subject: pyCGNS v1.0
Message-ID: <mailman.1038864726.23800.clpa-moderators@python.org>

-----------------------------------------------------------------------
pyCGNS v1.0

This package is a Python wrapper for CGNS (http://www.cgns.org)
It is useful for people doing archival, data exchange or pre/post
processing on CFD (Computational Fluid Dynamics) data.

-----------------------------------------------------------------------
This release covers 100% of CGNS v2.2 API and has one new proto tool.
The tool is cgg, a CGNS tree generator with an XML input. So far, it
can generate very basic trees.

-----------------------------------------------------------------------
Package pyCGNS uses CGNS, Python, Numeric Python and pyXML.
If you want more info, including the package download, please go to:

  http://elsa.onera.fr/CGNS/releases

-MP- 
-----------------------------------------------------------------------
 Marc POINOT             Alias: marcvs        Email: poinot@onera.fr
 ONERA -MFE/DSNA/ELSA    Tel: 01.46.73.42.84  Info: elsa-info@onera.fr
 29, Div. Leclerc        Fax: 01.46.73.41.66  Site:     
 92322 Chatillon FRANCE  Project: elsA        Web: http://www.onera.fr


From TrentM@ActiveState.com  Fri Nov 29 19:50:24 2002
From: TrentM@ActiveState.com (Trent Mick)
Date: Fri, 29 Nov 2002 11:50:24 -0800
Subject: ANN: ActivePython 2.2.2 released!
Message-ID: <mailman.1038864727.23815.clpa-moderators@python.org>

We are pleased to announce that version 2.2.2 of ActivePython is now
available for download from http://www.ActiveState.com/ActivePython
This is a bugfix release and supersedes previous ActivePython releases.

ActivePython is ActiveState's quality-assured binary build of Python.
Builds are currently available for Windows, Linux and Solaris.

In addition to the core, ActivePython features:
    * expat for XML processing;
    * zlib for data compression;
    * Tkinter for Tk development;
    * a large set of useful Python documentation; and, 
    * on Windows, Mark Hammond's PyWin32 extensions,
      including the Pythonwin IDE, support for Python ASP, the PythonCOM
      system.

Please submit email feedback to ActivePython-feedback@ActiveState.com,
and file bugs against ActivePython at
http://bugs.ActiveState.com/ActivePython.

Thanks, and enjoy!

Trent

-- 
Trent Mick
TrentM@ActiveState.com


From detlev@die-offenbachs.de  Sat Nov 30 17:12:49 2002
From: detlev@die-offenbachs.de (Detlev Offenbach)
Date: Sat, 30 Nov 2002 18:12:49 +0100
Subject: ANN: Eric 3.00-beta1 released
Message-ID: <mailman.1038864728.23829.clpa-moderators@python.org>

Hi,

Eric 3.0.0-beta1 is available for download via

http://www.die-offenbachs.de/detlev/eric3.html

This release contains some bugfixes and some of the requested features 
like an alternative layout for the main screen, smaller icons, 
capability to add all python/designer files of a directory to a project. 
For details see the history file in the distribution.

Please note that this is a feature freeze for 3.0.0. I will only fix bugs 
to get a stable release as soon as possible. New features will come with 
version 3.0.1.

What is it?
-----------
Eric 3.0.0 (or short eric3) is a Python IDE written using PyQt and 
QScintilla. It has integrated project management capabilities, it gives 
you an unlimited number of editors, an integrated Python shell, an 
integrated debugger and more.

Please see for yourself by visiting the a.m. page (it contains a picture 
of Eric our mascot as well).

Please report bugs, feature wishes or code contributions to 
eric-bugs@die-offenbachs.de

Help wanted!!
-------------
I would need some support in the area of more translations and user 
documentation. Any volunteers out there? Just let me know.

Regards,
Detlev
-- 
Detlev Offenbach
detlev@die-offenbachs.de


From adm@datafurnace.net.au  Sat Nov 30 23:06:59 2002
From: adm@datafurnace.net.au (Adam Bunter)
Date: Sun, 01 Dec 2002 09:06:59 +1000
Subject: ANN: Sayz Me 0.3 -  simple text-to-speech application
Message-ID: <mailman.1038864729.23843.clpa-moderators@python.org>

Sayz Me is a text-to-speech application for Windows. Text can be typed 
in or read from clipboard. Words are highlighted when spoken. User can 
adjust the reading speed and voice pitch.

Download from http://sourceforge.net/projects/sayzme/

Please note that this is my first ever python program (I am a vb / ms 
access developer in the process of defecting from the beast), so your 
feedback would be greatly appreciated.

Future plans include using a cross-platform open-source speech engine 
such as festival.

Cheers,

Adam Bunter
adm@datafurnace.net.au



From dyoo@hkn.eecs.berkeley.edu  Wed Nov 20 22:07:27 2002
From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo)
Date: Wed, 20 Nov 2002 17:07:27 -0500 (EST)
Subject: [Module] lovins/1.0
Message-ID: <mailman.1039039383.29114.clpa-moderators@python.org>

                               lovins/1.0                               
                               ----------                               

Lovins stemmer extension module

A thin wrapper around Linh Huynh's Lovins Stemmer implementation.


       URL:  http://hkn.eecs.berkeley.edu/~dyoo/python/py_lovins/
  Download:  http://hkn.eecs.berkeley.edu/~dyoo/python/py_lovins/lovins-1.0.tar.gz

   License:  GPL

  Categories:  Parsing/Formatting

Danny Yoo (dyoo@hkn.eecs.berkeley.edu)
http://hkn.eecs.berkeley.edu/~dyoo

--
<a href="http://hkn.eecs.berkeley.edu/~dyoo/python/py_lovins/">lovins/1.0</a>
-- Lovins stemmer extension module



From abpillai@lycos.com  Fri Nov 29 15:18:31 2002
From: abpillai@lycos.com (Anand Pillai)
Date: Fri, 29 Nov 2002 10:18:31 -0500 (EST)
Subject: [Application] PyWiew/0.2
Message-ID: <mailman.1039039383.29115.clpa-moderators@python.org>

                               PyWiew/0.2                               
                               ----------                               

Imageviewer application using wxPython/PIL

PyWiew is an imageviewer / editor application written entirely in python
using wxPython as the GUI element and wxPython/Python Imaging
Library(PIL) as the image manipulation framework.

Imageviewer written in wxPython using PIL

       URL:  http://www.angelfire.com/linux/anand
  Download:  http://www.angelfire.com/linux/anand/python/PyWiew.py

   License:  GPL
  Platform:  Win32, Linux
  Requires:  wxPython, PIL
  Binaries:  Not now
       Gui:  wxPython

  Categories:  Graphics, GUI

Anand Pillai (abpillai@lycos.com)
htt:/www.angelfire.com/linux/anand

--
<a href="http://www.angelfire.com/linux/anand">PyWiew/0.2</a> --
Imageviewer application using wxPython/PIL