Mailman 3 March 2001 - Python-announce-list

[Module] DMtools
by Ole＠vex.net March 15, 2001

March 15, 2001

DMtools ------- Support for data mining of MySQL databases. The DMtools are an efficient and flexible toolbox for accessing MySQL databases. They provide a number of routines for basic data aggregation which aim to facilitate various data mining tasks. Two core features of the DMtools are caching of database queries and parallelism within a collection of independent queries. URL: http://csl.anu.edu.au/ml/dm/dm_software.html Download: ftp://csl.anu.edu.au/pub/dm/dmtools/dmtools.tgz License: GPL Requires: MySQLdb, zlib (recommended) Categories: Database Ole Nielsen, Peter Christen (Ole.Nielsen(a)anu.edu.au, Peter.Christen(a)anu.edu.au) http://csl.anu.edu.au/ml/dm/ -- <a href="http://csl.anu.edu.au/ml/dm/dm_software.html">DMtools</a> -- Support for data mining of MySQL databases.

1 0

ReportLab commercial toolkit enters beta testing
by Andy Robinson March 15, 2001

March 15, 2001

ReportLab Inc. is introducing a new commercial product range which builds on our existing Open Source Python PDF generation toolkit. RML2PDF and PageCatcher are entering beta testing today. These are the first elements of a tightly integrated suite of packages for building world-class reporting solutions for the Web and back office. Report Markup Language and RML2PDF ---------------------------------- RML2PDF is a powerful tool which allows you to generate reports in PDF with simplicity, speed and flexibility, and without the level of programming knowledge you need to use our Open Source ReportLab toolkit. The primary market is web or application servers, though it can also be embedded in client applications. RML2PDF uses the Report Markup Language. RML is an XML dialect which is simple, flexible and powerful. It allows you to produce PDF documents that include drawings, photographs, multicolumn page layouts - all with the ease of writing basic HTML rather than raw PDF. Its even easier than Python. We offer an attractive package to resellers and consultants who already deliver solutions to their customers and who can use this as one more piece of their tool suite; and will consider licensing the technology for use within third party applications. See http://www.reportlab.com/rml/ PageCatcher ----------- This tool allows you to import graphical elements or whole pages from existing PDF files and use them in RMl2PDF or with our Open Source reporting tools. It can be used to - overprint PDF files with extra information - grab specific pages, reorder and assemble documents - save trees by doing 4-up versions of documents - use existing documents as 'forms' and draw over them It gives your graphic designers the freedom to use any tools they wish to design artwork, which can then be included in reports. It also opens up many possibilites for forms processing. See http://www.reportlab.com/pageCatcher/ What about the existing ReportLab toolkit? ------------------------------------------ The ReportLab toolkit is free, and will always be free. If you want to use Python to output PDF, then the ReportLab toolkit will always be available to you. RML2PDF is aimed at a different market: those organizations who want a "straight out of the box" solution, or those who arent Python-savvy. RML and any other commercial products we release will _always_ be in addition to the ReportLab toolkit and never replace it. If youre interested, send an email to mailto:info@reportlab.com. Or have a look at the products section on our web site: http://www.reportlab.com/rml/ Andy Robinson CEO and Chief Architect, ReportLab Inc.

1 0

python-dev summary, 2001-03-01 - 2001-03-15
by Michael Hudson March 15, 2001

March 15, 2001

This is a summary of traffic on the python-dev mailing list between Mar 1 and Mar 14 (inclusive) 2001. It is intended to inform the wider Python community of ongoing developments. To comment, just post to python-list(a)python.org or comp.lang.python in the usual way. Give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration) All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on a PEP if you have an opinion. This is the third python-dev summary written by Michael Hudson. Previous summaries were written by Andrew Kuchling and can be found at: <http://www.amk.ca/python/dev/> New summaries will appear at: <http://starship.python.net/crew/mwh/summaries/> and will continue to be archived at Andrew's site. Posting distribution (with apologies to mbm) Number of articles in summary: 264 50 | ]|[ | ]|[ | ]|[ | ]|[ 40 | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ ]|[ 30 | ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ 20 | ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 10 | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 0 +-050-022-012-004-009-006-003-002-003-005-017-059-041-031 Thu 01| Sat 03| Mon 05| Wed 07| Fri 09| Sun 11| Tue 13| Fri 02 Sun 04 Tue 06 Thu 08 Sat 10 Mon 12 Wed 14 A quiet fortnight on python-dev; the conference a week ago is responsible for some of that, but also discussion has been springing up on other mailing lists (including the types-sig, doc-sig, python-iter and stackless lists, and those are just the ones your author is subscribed to). * Bug Fix Releases * Aahz posted a proposal for a 2.0.1 release, fixing the bugs that have been found in 2.0 but not adding the new features. <http://mail.python.org/pipermail/python-dev/2001-March/013389.html> Guido's response was, essentially, "Good idea, but I don't have the time to put into it", and that the wider community would have to put in some of the donkey work if this is going to happen. Signs so far are encouraging. * Numerics * Moshe Zadka posted three new PEP-drafts: <http://mail.python.org/pipermail/python-dev/2001-March/013435.html> which on discussion became four new PEPs, which are not yet online (hint, hint). The four titles are Unifying Long Integers and Integers Non-integer Division Adding a Rational Type to Python Adding a Rational Literal to Python and they will appear fairly soon at <http://python.sourceforge.net/peps/pep-0237.html> <http://python.sourceforge.net/peps/pep-0238.html> <http://python.sourceforge.net/peps/pep-0239.html> <http://python.sourceforge.net/peps/pep-0240.html> respectively. Although pedantically falling slightly out of the remit of this summary, I should mention Guido's partial BDFL pronouncement: <http://mail.python.org/pipermail/python-dev/2001-March/013587.html> A new mailing list had been setup to discuss these issues: <http://lists.sourceforge.net/lists/listinfo/python-numerics> * Revive the types-sig? * Paul Prescod has single-handedly kicked the types-sig into life again. <http://mail.python.org/sigs/types-sig/> The discussion this time seems to be centered on interfaces and how to use them effectively. You never know, we might get somewhere this time! * stackless * Jeremy Hylton posted some comments on Gordon McMillan's new draft of the stackless PEP (PEP 219) and the stackless dev day discussion at Spam 9. <http://mail.python.org/pipermail/python-dev/2001-March/013494.html> The discussion has mostly focussed on technical issues; there has been no comment on if or when the core Python will become stackless. * miscellanea * There was some discussion on nested scopes, but mainly on implementation issues. Thomas Wouters promised <wink> to sort out the "continue in finally: clause" wart. Cheers, M.

1 0

PEP 6: Patch and Bug Fix Releases
by aahz＠panix.com March 14, 2001

March 14, 2001

[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to python-dev] Okay, folks, here it is, the first draft of the spec for creating Python maintenance releases. Note that I'm not on python-dev, so it's probably better to have the discussion on c.l.py if possible. PEP: 6 Title: Patch and Bug Fix Releases Version: $Revision: 1.1 $ Author: aahz(a)pobox.com (Aahz) Status: Draft Type: Informational Created: 15-Mar-2001 Post-History: _________________________________________________________________ Abstract 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 the work. Motivation 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 old feature releases, providing bug fixes and (minimal!) feature additions. This will make Python more attractive for enterprise development, where Python may need to be installed on hundreds or thousands of machines. At the same time, many of the core Python developers are understandably reluctant to devote a significant fraction of their time and energy to what they perceive as grunt work. On the gripping hand, people are likely to feel discomfort around installing releases that are not certified by PythonLabs. Prohibitions 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 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. Bug Fix Releases Bug fix releases are a subset of all patch releases; it is prohibited to add any features to the core in a bug fix release. A patch release that is not a bug fix release may contain minor feature enhancements, subject to the Prohibitions section. The standard for patches to extensions and modules is a bit more lenient, to account for the possible desirability of including a module from a future version that contains mostly bug fixes but may also have some small feature changes. (E.g. Fredrik Lundh making available the 2.1 sre module for 2.0 and 1.5.2.) Version Numbers Starting with Python 2.0, all feature releases are required to have the form X.Y; patch releases will always be of the form X.Y.Z. To clarify the distinction between a bug fix release and a patch release, all non-bug fix patch releases will have the suffix "p" added. For example, "2.1" is a feature release; "2.1.1" is a bug fix release; and "2.1.2p" is a patch release that contains minor feature enhancements. Procedure XXX This section is still a little light (and probably controversial!) The Patch Czar is the counterpart to the BDFL for patch releases. However, the BDFL and designated appointees retain veto power over individual patches and the decision of whether to label a patch release as a bug fix release. As individual patches get contributed to the feature release fork, each patch contributor is requested to consider whether the patch is a bug fix suitable for inclusion in a patch release. If the patch is considered suitable, the patch contributor will mail the SourceForge patch (bug fix?) 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[1]. 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 as a beta release. If any new bugs are found, they must be fixed and a new beta release publicized. Once a beta cycle completes with no new bugs found, the package is sent to PythonLabs for certification and publication on python.org. Each beta cycle must last a minimum of one month. Issues To Be Resolved Should the first patch release following any feature release be required to be a bug fix release? (Aahz proposes "yes".) Is it allowed to do multiple forks (e.g. is it permitted to have both 2.0.2 and 2.0.2p)? (Aahz proposes "no".) Does it makes sense for a bug fix release to follow a patch release? (E.g., 2.0.1, 2.0.2p, 2.0.3.) Exactly how does a candidate patch release get submitted to PythonLabs for certification? And what does "certification" mean, anyway? ;-) Who is the Patch Czar? Is the Patch Czar a single person? (Aahz says "not me alone". Aahz is willing to do a lot of the non-technical work, but Aahz is not a C programmer.) 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.) References [1] PEP 3, Hylton, http://python.sourceforge.net/peps/pep-0003.html Copyright This document has been placed in the public domain.

1 0

ANN: First alpha release of Jython-2.1
by bckfnn＠worldonline.dk March 14, 2001

March 14, 2001

I am happy to announce the first alpha release of Jython 2.1. Jython is a Java implementation of the Python programming language. It allows users to compile Python source code to Java byte codes, and run the resulting bytecodes on any Java Virtual Machine. It is a very seamless and smooth integration with Java: from Python you have complete access to all Java libraries, can build applets, can integrate with Java beans, and can subclass Java classes in Python and vice versa. Like Python, and unlike Java, Jython can also be used interactively: just type some Jython code at the prompt and see the results immediately. A java installer is available for download at the Jython website: http://www.jython.org/ Installation of version 2.1a1 is similar to version 2.0. Further information and tips on installation is available at: http://www.jython.org/install.html Jython 2.1 aims to be feature compatible with Python 2.1 and among the new feature are: - Nested scopes - The warning framework - Rich comparison - The numeric coercion model have changed. - Function attributes. The changes from Jython-2.0 include: New features. - Improve speed when indexing a string and iterating over a string in a for loop. - Reworked coercing model (pep-0208) - Added {}.popitem(). - Improved speed for python files by buffering the RandomAccessFile. - Added function attributes (pep-0232) - Rich comparison (pep-0207) - Updated cPickle to handle CPython compatible unicode strings. - Updated sre to CPython-2.1a1 - Added the "new" module - Added a PyServlet class to the util package. - Warning framework (pep-0230). - Added sys.add_classdir and sys.add_extdir. - Added nested scope to the interpreter (pep-0227). Bug fixes. - Allow self referencing adapters to be collected when using weak tables. - Added workaround for a reader bug in MRJ22Jitc.01. - Fixes #127340 where serializable parameter received a PyObject instead of the wrapped java object. - Include a LineNumberTable in the compiled class files. - Fixed a java version test bug in the installer. A complete list of changes and differences are available here: http://www.jython.org/NEWS.html Bugs can be reported to the bug manager on SourceForge: http://sourceforge.net/bugs/?group_id=12867 Cheers, the jython-developers

1 0

MS-SQL2000 XML/HTTP interface
by Luke Kenneth Casson Leighton March 14, 2001

March 14, 2001

the first platform-independent python db module to allow access to a microsoft SQL 2000 database has been released. it is based on andy dustman's MySQLdb module, so is close to the DB 2.0 API. this project can be found at http://sourceforge.net/projects/pyxsqmll. this project is one of those interesting necessities that "does the job for me". hence, the version number of the current release, despite being based on MySQLdb 0.3.0, is ramped down to 0.0. requirements: py-xml 0.6.2 or greater (0.6.2 confirmed working and 0.6.4 confirmed working). python 2.0 (confirmed working - lower versions not tested). Microsoft's SQL 2000 server Microsoft's IIS server with the SQL-2000 XML plug-in installed. have fun, enjoy python, it's utterly cool. ["come on i, the water's fine*snap*aaaiieee!"] luke ----- Luke Kenneth Casson Leighton <lkcl(a)samba-tng.org> ----- "i want a world of dreams, run by near-sighted visionaries" "good. that's them sorted out. now, on _this_ world..."

1 0

[ANNOUNCE] Using Mix-ins with Python
by Chuck Esterbrook March 13, 2001

March 13, 2001

There is a Python article in the April 2001 issue of the Linux Journal, "Using Mix-ins with Python". It covers the general topic of mix-in programming with some comments on various languages, and then dives into Python specifics including examples. I used these concepts when creating the MiddleKit component of Webware (http://webware.sourceforge.net/), which includes a mix-in function in Webware.MiscUtils.MixIn. -Chuck -- Get web dev at http://webware.sourceforge.net/

1 0

ANN: python-cdb 0.21
by M.J. Pomraning March 13, 2001

March 13, 2001

python-cdb 0.21 --------------- cdb files are mappings of keys to values, designed for wickedly fast lookups and atomic updates. The file format is used in mission critical applications like email, DNS, RADIUS, etc. This module provides a dict-like interface to cdb files, as well as facilities for iteration and database creation. The module attempts to mimic all of the functionality of the utilities from the cdb library package. gdbm fans will be pleased to note that CDB objects support firstkey()/nextkey() iteration. See http://pilcrow.madison.wi.us/ for download and related information. See http://cr.yp.to/cdb.html for info on the cdb format. 0.21 is a feature complete (I hope) beta, tested under Python 1.5.2. It is the same as the 0.20 release, the first public release, but (thankfully) with distutils integration. Any feedback is welcome. -Mike -- MJ Pomraning mjp(a)pilcrow.madison.wi.us <P><A HREF="http://pilcrow.madison.wi.us/">python-cdb 0.21</A> - High-level interface to constant databases

1 0

payment processor integration with Python
by Russ Cobbe March 12, 2001

March 12, 2001

Might be useful to python users and hopefully you can let them know about it. oPAYc is a standardized way to do payment processing to a large number of different payment processing companies. oPAYc supports all of the major processing companies and can be implemented into most web sites using common programming languages including Python. It has been built to be easy to integrate into any web based application by doing database calls. Features: - very simple standardized code to do a transaction - examples for most major web programming languages - easy integration to any web site - detailed documentation Benefits: - time to market is much quicker - less costly than custom programming an interface to the payment processor - easy to switch payment processing companies Processors supported include CyberCash, Signio/Verisign, iBILL, Authorize.NET, ICS Paypoint, Cardservices/Linkpoint/PSIGate, TeleCheck, Surepay, Echo, Cybersource, ClearCommerce, Clearlink, Pure Payments, GeoPay and E-xact. More being added all the time. More info email info(a)opayc.com or visit http://www.opayc.com Russ Cobbe President, Inline Internet Systems, Inc. 405 Britannia Road E, Suite 212 Mississauga, ON L4Z 3E2 P: (905) 712 3841 F: (905) 712 2965 http://www.inline.net http://www.ihtml.com Web Application Servers, E-Commerce Solutions

1 0

ANNOUNCE Mailman 2.0.3
by barry＠digicool.com March 12, 2001

March 12, 2001

[I think I forgot to announce the Mailman 2.0.2 release on these mailing lists. Apologies. -Barry] I've just announced the 2.0.3 release of Mailman, the GNU Mailing List Manager. Mailman is released under the GNU General Public License (GPL). I highly recommend that all sites running earlier versions of Mailman upgrade to 2.0.3. This release includes the important privacy patch from Mailman 2.0.2. Sadly, Mailman 2.0.2 contained a small but nasty typo requiring this new version. Mailman 2.0.3 is being released as both a gzip'd source tarball and as a patchfile. 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.3 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: http://mailman.sourceforge.net http://www.list.org [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.2 -> 2.0.3 patch, please see: http://sourceforge.net/project/showfiles.php?group_id=103 There are email lists (managed by Mailman, of course!) for both Mailman users and developers. See the web sites above for details. Enjoy, -Barry

1 0