Description: a platform-independent means to access Microsoft SQL 2000.
Dependencies: python 2.0 or greater, because i like the += operator.
Functionality: uses HTTP Basic Authentication.
: identical API to MySQLdb 0.3 (which is Python DB 2.0
compliant but i'm not sure about pyxsqmll: i removed
some of the functions and haven't needed them,
: pyxsqmsll2000.py is a stand-alone program that accepts
SQL commands on standard-input (note: no prompt given!)
Recent changes: removed usage of py-xml-0.6.4 because it was waay
to memory-heavy and time-consuming (sorry, guys).
A 2.5mb response (with 800 records) took 45mb and
30 seconds to process. using the standard distro
xmllib now _only_ takes 8mb and 10 seconds...
python r0kz. [start getting worried when i add 'mi world' at the end]
The latest version of SOAP.py (a SOAP implementation in written in Python),
was released today. Check out it's interop matrix,
http://www.actzero.com/interop.html or download it,
Comments, feedback, patches, etc... very welcome.
- General SOAP Parser based on sax.xml (requires Python 2.0 or later)
- General SOAP Builder
- SOAP Proxy for RPC client code
- SOAP Server framework for RPC server code
- Handles all of the types in the BDG
- Handles faults
- Allows namespace specification
- Allows SOAPAction specification
- Homogeneous typed arrays
- Supports multiple schemas
- Header support ( mustUnderstand and actor)
- Early XML attribute support (parsing only)
- Good interop http://www.actzero.com/interop.html
VERSION 0.7 (4/19/01)
- Fixed a bug that caused nothing to work with Python 2.1
- Float work arounds for WIN32 (others?)
- DateTime parsing for WIN32
- Beginnings of XML attribute support
- Better interop
VERSION 0.6 (4/18/01)
- Fixed numerous bugs (dateTime, float prec., Response Element, null
- Added more types
- Homogeneous typed arrays
- Added support for more schemas
- Early Header support and mustUnderstand and actor
- Added interop suite
- Passes validator
- Interop greatly improved, passes all client tests for Frontier,
VERSION 0.5 (4/17/01)
- Initial public release
MP3View / 2.0
A console based MP3 player with sound cues
MP3View is a console based MP3 playlist display that uses a curses style
interface, compatible with any TTY or VT100 terminal. The option to play
a WAV file to announce events within the application is supported. The
application was designed to run on a small terminal over a serial line,
as a controller for a car MP3 player, but is easily adaptable to any
terminal. An external program (such as mpg123) is used to play the
selected MP3 file.
Comments and suggestions for further development are welcome, and may be
sent to rupe(a)metro.yak.net.
License: Public Domain
Platform: Linux / UNIX
Requires: external mp3 player (mpg123), mixer (aumix), optional wav player (dreamplay)
<a href="http://metro.yak.net/mp3view.html">MP3View / 2.0</a> -- A
console based MP3 player with sound cues
I updated Hernan Foffani's pythlp.py script to generate python 2.1
documentation in Windows HTML Help format.
Both the script and the help file are available:
greet / 1.0
greet plays a time appropriate voice greeting and status message
greet 1.0 says 'good morning', 'good afternoon', or 'good evening' based
on the system time. A status message follows, which is determined by the
first command line argument. Useful for providing system powerup /
powerdown confirmation when visual cues such as LEDs, fan noise, or a
display might not be visible or viable sources of information. This
application was originally developed for an MP3 system in the trunk of a
Comments, additions, and suggestions for further development are
welcome, and may be sent to rupe(a)metro.yak.net.
License: Public Domain
Requires: greet requires a system with audio capabilities, and a command line wav player utility
<a href="http://metro.yak.net/greet.html">greet / 1.0</a> -- greet plays
a time appropriate voice greeting and status message
I've just released version 2.0.4 of Mailman, the GNU Mailing List
Manager. Mailman is released under the GNU General Public License
Mailman 2.0.3 had a few constructs which caused warnings when run with
Python 2.1. The unfortunate part is that those warnings could occur
in the qrunner process which tended to cause cron to bombard the
system administrators with email. If you upgrade your Python to 2.1,
you should definitely upgrade to Mailman 2.0.4, otherwise consider it
Mailman 2.0.4 is being released as both a gzip'd source tarball and as
a patch file.
GNU Mailman is software to help manage electronic mail discussion
lists, much like Majordomo or Smartmail. Mailman gives each mailing
list a unique web page and allows users to subscribe, unsubscribe, and
change their account options over the web. Even the list manager can
administer his or her list entirely via the web. Mailman has most of
the features that people want in a mailing list management system,
including built-in archiving, mail-to-news gateways, spam filters,
bounce detection, digest delivery, and so on.
Mailman is compatible with most web servers, web browsers, and mail
servers. It runs on GNU/Linux and should run on any other Unix-like
operating system. Mailman 2.0.4 requires Python 1.5.2 or newer. To
install Mailman from source, you will need a C compiler.
For more information on Mailman, including links to file downloads,
please see the Mailman WWW page: http://www.gnu.org/software/mailman
And its mirrors at:
[Only the SourceForge and list.org sites are up-to-date at the moment,
I expect the gnu.org site to be updated shortly.]
If you want to download just the 2.0.3 -> 2.0.4 patch, please see:
There are email lists (managed by Mailman, of course!) for both
Mailman users and developers. See the web sites above for details.
[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to
[Barry, please update Post-History]
Okay, here's the next version of PEP 6:
Title: Bugfix Releases
Version: $Revision: 1.3 $
Author: aahz(a)pobox.com (Aahz)
Python has historically had only a single fork of development, with
releases having the combined purpose of adding new features and
delivering bug fixes (these kinds of releases will be referred to as
"feature releases"). This PEP describes how to fork off patch
releases of old versions for the primary purpose of fixing bugs.
This PEP is not, repeat NOT, a guarantee of the existence of patch
releases; it only specifies a procedure to be followed if patch
releases are desired by enough of the Python community willing to do
With the move to SourceForge, Python development has accelerated.
There is a sentiment among part of the community that there was too
much acceleration, and many people are uncomfortable with upgrading
to new versions to get bug fixes when so many features have been
added, sometimes late in the development cycle.
One solution for this issue is to maintain the previous feature
release, providing bugfixes until the next feature release. This
should make Python more attractive for enterprise development, where
Python may need to be installed on hundreds or thousands of machines.
Patch releases are required to adhere to the following restrictions:
1. There must be zero syntax changes. All .pyc and .pyo files must
work (no regeneration needed) with all patch releases forked off
from a feature release.
2. There must be zero pickle changes.
3. There must be no incompatible C API changes. All extensions must
continue to work without recompiling in all patch releases in the
same fork as a feature release.
Breaking any of these prohibitions requires a BDFL proclamation (and
a prominent warning in the release notes).
Starting with Python 2.0, all feature releases are required to have
a version number the form X.Y; patch releases will always be of the
The current feature release under development is referred to as
release N; the just-released feature version is referred to as N-1.
The process for managing patch releases is modeled in part on the
Tcl system .
The Patch Czar is the counterpart to the BDFL for patch releases.
However, the BDFL and designated appointees retain veto power over
As individual patches get contributed to the feature release fork,
each patch contributor is requested to consider whether the patch is
a bugfix suitable for inclusion in a patch release. If the patch is
considered suitable, the patch contributor will mail the SourceForge
patch (bugfix?) number to the maintainers' mailing list.
In addition, anyone from the Python community is free to suggest
patches for inclusion. Patches may be submitted specifically for
patch releases; they should follow the guidelines in PEP 3 .
The Patch Czar decides when there are a sufficient number of patches
to warrant a release. The release gets packaged up, including a
Windows installer, and made public. If any new bugs are found, they
must be fixed immediately and a new patch release publicized (with an
incremented version number).
Patch releases are expected to occur at an interval of roughly one
month. In general, only the N-1 release will be under active
maintenance at any time.
Patch Czar History
Moshe Zadka (moshez(a)zadka.site.co.il) is the Patch Czar for 2.0.1.
Issues To Be Resolved
What is the equivalent of python-dev for people who are responsible
for maintaining Python? (Aahz proposes either python-patch or
python-maint, hosted at either python.org or xs4all.net.)
Does SourceForge make it possible to maintain both separate and
combined bug lists for multiple forks? If not, how do we mark bugs
fixed in different forks? (Simplest is to simply generate a new bug
for each fork that it gets fixed in, referring back to the main bug
number for details.)
This PEP started life as a proposal on comp.lang.python. The
original version suggested a single patch for the N-1 release to be
released concurrently with the N release. The original version also
argued for sticking with a strict bugfix policy.
Following feedback from the BDFL and others, the draft PEP was
written containing an expanded patch release cycle that permitted
any previous feature release to obtain patches and also relaxed the
strict bugfix requirement (mainly due to the example of PEP 235 ,
which could be argued as either a bugfix or a feature).
Discussion then mostly moved to python-dev, where BDFL finally
issued a proclamation basing the Python patch release process on
Tcl's, which essentially returned to the original proposal in terms
of being only the N-1 release and only bugfixes, but allowing
multiple patch releases until release N is published.
This document has been placed in the public domain.
The Python Shelf!
All the docs you use to like in one package! Includes:
- Python 2.1 Documentation,
- the output of Ping's pydoc (python 2.1 version),
- Python Frequently Asked Questions (up to March 08 2001),
- IDLE explained,
- an Introduction to Tkinter (by Fredrik Lundh),
- and the HOWTOs.
These docs are in Microsoft HTML Help format. You can use them together
with full search text or on individual basis. Works on Windows OS.
(Please, can anyone check if these .chm files works on Macs
with IE 4.x or 5.x? Thanks.)
Hernan M. Foffani (hfoffani(a)yahoo.com)
<a href="http://www.orgmf.com.ar/condor/pytstuff.html">Python Shelf</a> --
The most useful docs for Python on Microsoft HTML Help format.
On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
>Yes, the *final* release of Python 2.1 is now available. Thanks again
I've updated my set of RPMs against 2.1. I've similarly upgraded my 2.1
beta announcement to 2.1 final, and am including it below. Changes in this
Upgrade to 2.1 final.
Binary and package name is "python2" by default. Comment out the first
(non-comment) line of the .spec file to build "python".
Fixes the path to python2 in pydoc based on the above.
Uses "--with-pymalloc" when configuring.
Included Tony Seward's patch to fix the expat module's header path.
Split out devel and tkinter packages.
Shy of RPMs because of library or other dependancy problems with most of
the RPMs you pick up? The cure, in my experience is to pick up an SRPM.
All you need to do to build a binary package tailored to your system is run
"rpm --rebuild <packagename>.src.rpm".
The Source RPM and binaries for RedHat and KRUD 7.0 are at:
You'll also need the following to build the SRPMSs:
(Note, KRUD is our RedHat-based distribution with all errata applied.
Binaries should work on a stock RedHat 7.0 system, particularly if you have
the errata applied).
Again, this one builds the executable as "python2", and can be installed
along-side your normal Python on the system. Want to check out a great new
feature? Type "pydoc string" or "pydoc -g" from your shell.
Download the SRPM from above, and most users can install a binary built
against exactly the set of packages on their system by doing:
rpm --rebuild expat-1.1-3tummy.src.rpm
rpm -i /usr/src/redhat/RPMS/i386/expat*-1.1-3tummy.i386.rpm
rpm --rebuild python-2.1b2-1tummy.src.rpm
rpm -i /usr/src/redhat/RPMS/i386/python*2.1b1-1tummy.i386.rpm
The structure of a system reflects the structure of the organization that
built it. -- Richard E. Fairley
Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
On Tue, Apr 17, 2001 at 09:29:44AM -0500, Guido van Rossum wrote:
> - ports to several new platforms, including Cygwin and RISCOS
I have contributed Python to the standard Cygwin distribution. Cygwin
Python is located in the contrib/python directory on the Cygwin mirrors.
Cygwin's setup.exe will automatically install Cygwin Python the next
time one installs or updates from a mirror.
If interested, see the following for a copy of the announcement:
I kindly request that people post to python-list(a)python.org or
cygwin(a)sources.redhat.com as appropriate instead of emailing me
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler(a)dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com