Mailman 3 March 2001 - Python-announce-list

ANN: eGenix.com mxODBC Database Interface Version 2.0.1
by M.-A. Lemburg March 30, 2001

March 30, 2001

________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Package for Python Version 2.0.1 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mxODBC Database Package for Python is part of the eGenix.com mx Extension Series for Python, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. ________________________________________________________________________ WHAT'S NEW ? This patch release fixes a few problems which were found by users on Windows platforms: * Execution of SQL commands lead to a hanging Python processes for some users. * Handling of date/time values resulted in exceptions on some Windows configurations. Due to popular demand, I am now also providing precompiled Windows binaries for the older Python 1.5.2 version. Binaries for Python 2.1 will be announced after its final release. ________________________________________________________________________ SPECIAL OFFER theKompany.com has licensed the eGenix.com mx Commercial Package (which includes mxODBC) for inclusion in their brand new Qt-based Python IDE BlackAdder. It allows developing portable GUI-based database applications which run on Windows and Linux platforms without any change to the source code. BlackAdder includes a 1 CPU license for this package at no extra cost, so you may want to check out their great new product. See http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#BlackAdder for details. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.lemburg.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.lemburg.com/files/python/ Note that in order to use mxODBC you will also need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? mxODBC comes with a licenses which allows non-commercial use at no charge, but costs a moderate fee for commercial use. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#mxCOMMERCIAL for details. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ REFERENCE: <P><A HREF="http://www.lemburg.com/files/python/">eGenix.com mxODBC Package</A> - eGenix.com mxODBC Database Interface 2.0.1 with distutils support and precompiled binaries for Windows and Linux. (31-Mar-2001) ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/

1 0

Scientific Python 2.2
by Konrad Hinsen March 30, 2001

March 30, 2001

Scientific Python 2.2 --------------------- Scientific Python is a module library for scientific computing. In this collection you will find modules that cover basic geometry (vectors, tensors, transformations, vector and tensor fields), quaternions, automatic derivatives, (linear) interpolation, polynomials, elementary statistics, nonlinear least-squares fits, unit calculations and conversions, Fortran-compatible text formatting, 3D visualization via VRML, two Tk widgets for simple line plots and 3D wireframe models. Scientific Python also contains Python interfaces to the netCDF library (implementing a portable binary format for large arrays) and the Message Passing Interface, the most widely used communications library for parallel computers. Version 2.2 of Scientific Python has just been released. In addition to numerous small improvents and bug fixes, it contains the first stable release of the MPI interface. It is also the first release to use the new distutils package in order to facilitate installation. For more information and for downloading, see http://starship.python.net/crew/hinsen/scientific.html or http://dirac.cnrs-orleans.fr/programs/scientific.html -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen(a)cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------

1 0

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

March 29, 2001

This is a summary of traffic on the python-dev mailing list between Mar 15 and Mar 28 (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 fourth summary written by Michael Hudson. Summaries are archived at: <http://starship.python.net/crew/mwh/summaries/> Posting distribution (with apologies to mbm) Number of articles in summary: 410 50 | [|] | [|] | [|] | [|] 40 | [|] | [|] [|] | [|] [|] [|] | [|] [|] [|] [|] [|] 30 | [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] 20 | [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 0 +-044-024-013-029-059-046-040-022-040-031-007-019-008-028 Thu 15| Sat 17| Mon 19| Wed 21| Fri 23| Sun 25| Tue 27| Fri 16 Sun 18 Tue 20 Thu 22 Sat 24 Mon 26 Wed 28 Bug-fixing for 2.1 remained a priority for python-dev this fortnight which saw the release of 2.1b2 last Friday. * Python 2.0.1 * Aahz posted his first draft of PEP 6, outlining the process by which maintenance releases of Python should be made. <http://python.sourceforge.net/peps/pep-0006.html> Moshe Zadka has volunteered to be the "Patch Czar" for Python 2.0.1. <http://mail.python.org/pipermail/python-dev/2001-March/013952.html> I'm sure we can all join in the thanks due to Moshe for taking up this tedious but valuable job! * Simple Generator implementations * Neil Schemenauer posted links to a couple of "simple" implementations of generators (a.k.a. resumable functions) that do not depend on the stackless changes going in. <http://mail.python.org/pipermail/python-dev/2001-March/013648.html> <http://mail.python.org/pipermail/python-dev/2001-March/013666.html> These implementations have the advantage that they might be applicable to Jython, something that sadly cannot be said of stackless. * portable file-system stuff * The longest thread of the summary period started off with a request for a portable way to find out free disk space: <http://mail.python.org/pipermail/python-dev/2001-March/013706.html> After a slightly acrimonious debate about the nature of Python development, /F produced a patch that implements partial support for os.statvfs on Windows: <http://sourceforge.net/tracker/index.php?func=detail&aid=410547&group_id=54…> which can be used to extract such information. A side-product of this discussion was the observation that although Python has a module that does some file manipulation, shutil, it is far from being as portable as it might be - in particular it fails miserably on the Mac where it ignores resource forks. Greg Ward then pointed out that he had to implement cross-platform file copying for the distutils <http://mail.python.org/pipermail/python-dev/2001-March/013962.html> so perhaps all that needs to be done is for this stuff to be moved into the core. It seems very unlikely there will be much movement here before 2.2.

1 0

MacPython 2.1b2 available
by jack＠oratrix.nl March 28, 2001

March 28, 2001

MacPython 2.1b2 is available for download. Get it via http://www.cwi.nl/~jack/macpython.html . New in this version: - A choice of Carbon or Classic runtime, so runs on anything between MacOS 8.1 and MacOS X - Distutils support for easy installation of extension packages - BBedit language plugin - All the platform-independent Python 2.1 mods - New version of Numeric - Lots of bug fixes - Choice of normal and active installer Please send feedback on this release to pythonmac-sig(a)python.org, where all the maccies hang out. Enjoy, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

1 0

Pymmetry - Python Trust Metrics
by Luke Kenneth Casson Leighton March 27, 2001

March 27, 2001

Pymmetry - http://sourceforge.net/projects/pymmetry dependencies: any version of python that supports the "+=" operator (2.0 and above only?). other than that, it's pretty much self-contained code. Raph Levien's net_flow.c and tmetric.c - ported to python (from mod_virgule - running advogato.org) Contains an implementation of the Ford-Fulkerson Maximum Flow algorithm. Uses this algorithm in a way that is effectively "Cascading (or Hierarchical) Access Control". Pymmetry 1.0 example usage code includes a text-based profile / user-certifications implementation. python r0kz. 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

Release 2.0.1: Heads Up
by Moshe Zadka March 26, 2001

March 26, 2001

Greetings, earthlings! As Guido said in the last conference, there is going to be a bugfix release of Python 2.0, Python 2.0.1. Originally meant to be only a license bugfix release, comments in the Python community have indicated a need for a real bugfix release. PEP 6[1] has been written by Aahz, which outlines a procedure for such releases. With Guido's blessing, I have volunteered to be the Patch Czar (see the PEP!) for the 2.0.1 release. In this job, I intend to be feared and hated throughout the Python community -- men will tremble to hear the sounds of my footsteps...err...sorry, got sidetracked. This is the first Python pure bugfix release, and I feel a lot of weight rests on my shoulders as to whether this experiment is successful. Since this is the first bugfix release, I intend to be ultra-super-conservative. I can live with a release that does not fix all the bug, I am very afraid of a release that breaks a single person's code. Such a thing will give Python bugfix releases a very bad reputation. So, I am going to be a very strict Czar. I will try to follow consistent rules about which patches to integrate, but I am only human. I will make all my decisions in the public, so they will be up for review of the community. There are a few rules I intend to go by 1. No fixes which you have to change your code to enjoy. (E.g., adding a new function because the previous API was idiotic) 2. No fixes which have not been applied to the main branch, unless they are not relevant to the main branch at all. I much prefer to get a pointer to an applied patch or cvs checkin message then a fresh patch. Of course, there are cases where this is impossible, so this isn't strict. 3. No fixes which have "stricter checking". Stricter checking is a good thing, but not in bug fix releases. 4. No fixes which have a reasonable chance to break someone's code. That means that if there's a bug people have a good change of counting on, it won't be fix. 5. No "improved documentation/error message" patches. This is stuff that gets in people's eyeballs -- I want bugfix upgrade to be as smooth as possible. 6. No "internal code was cleaned up". That's a good thing in the development branch, but not in bug fix releases. Note that these rules will *not* be made more lenient, but they might get stricter, if it seems such strictness is needed in order to make sure bug fix releases are smooth enough. However, please remember that this is intended to help you -- the Python using community. So please, let me know of bugfixes that you need or want in Python 2.0. I promise that I will consider every request. Note also, that the Patch Czar is given very few responsibilities --- all my decisions are subject to Guido's approval. That means that he gets the final word about each patch. I intend to post a list of patches I intend to integrate soon -- at the latest, this Friday, hopefully sooner. I expect to have 2.0.1a1 a week after that, and further schedule requirements will follow from the quality of that release. Because it has the dual purpose of also being a license bugfix release, schedule might be influenced by non-technical issues. As always, Guido will be the final arbitrator. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez(a)debian.org |http://www.{python,debian,gnu}.org

1 0

ANN: PythonWorks Pro 1.2
by PythonWare March 26, 2001

March 26, 2001

a pythonware newsflash: Secret Labs AB has released a new, much improved version of their integrated development environment for Python. PythonWorks is a rapid application development tool, designed for efficient development in Python. PythonWorks includes editors, a debugger, a user-interface design tool, project browser, deployment tools, integrated on-line help, and a scriptable environment. PythonWorks is well suited for many tasks, including: + Cross-platform system administration (system automation) + Prototyping of user interfaces and full applications + Building test frameworks + Rapid development and deployment of complete applications New features in 1.2 include improved support for Python 2.0, support for multiple pads and views, directory workspaces, lots of editor improvements, basic class browser, and improved EXE deployment support. Beginning with version 1.2, Secret Labs is also offering OEM versions of PythonWorks, for customers who want to provide a powerful IDE environment as part of their own Python-powered applications, or want a customized version of PythonWorks for use in their organization. To learn more, visit the PythonWorks product site: http://www.pythonworks.com You can also mail us at info(a)pythonware.com regards, the pythonworks team

1 0

[ANN] PyBSDDB 3.0 final released
by Robin Dunn March 24, 2001

March 24, 2001

Since there have been no trouble reports for some time I have decided to shift PyBSDDB 3.0 out of beta and have made a final release. You can get it here: http://sourceforge.net/project/showfiles.php?group_id=13900&release_id=28477 Binaries are provided for win32 and Linux (RPMs). The source distribution should build using distutils anywhere else that Sleepycat DB is supported. Description: ------------ Berkeley DB is a programmatic toolkit that provides high-performance built-in database support for desktop and server applications. The Berkeley DB access methods include B+tree, Extended Linear Hashing, Fixed and Variable-length records, and Queues. Berkeley DB provides full transactional support, database recovery, online backups, multi-threaded and multi-process access, etc. The Python wrappers allow you to store Python string objects of any length, keyed either by strings or integers depending on the database access method. With the use of another module in the package standard shelve-like functionality is provided allowing you to store any picklable Python object! Additional details, including online docs, are available here: http://pybsddb.sourceforge.net/ -- Robin Dunn Software Craftsman robin(a)AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!

1 0

[ANN] HappyDoc 1.4 released
by Doug Hellmann March 24, 2001

March 24, 2001

Announcing the latest version of HappyDoc, a Python documentation extraction tool. HappyDoc is a tool for extracting documentation from Python source code. It differs from other such applications by the fact that it uses the parse tree for a module to derive the information used in its output, rather that importing the module directly. This allows the user to generate documentation for modules which need special context to be imported. Version 1.4 -- - Handle Packages separately from Modules. This behavior is optional and consists mostly of creating intermediate level TOC pages and not showing subdirectories of a Package on the Package's parent TOC page. - Changed default title to include instructions about how to change the title - Show exceptions in plugins when there is a problem loading a module - Added a command line argument to support ignoring specific subdirectories. - Fixed problem with ignoring directories by correcting name comparison logic. - Change "link":URL style references which were HTML quoted back to StructuredText so that hyperlinks can be embedded within docstrings. (reported by Mihalopoulos Evangelos) - Changed base class arrangement for docset so the basic interface is documented as part of the docset base class. - Moved some formatter functions into the docset, since they match that API better and more properly belong there. - Fixed bug 131751, problem with string dereference in parseinfo.py - Set the DOCTYPE in hdformatter_htmlfile.py. (Thanks to Shannon -jj Behrens for the patch.) - Fixed problem with references to extra files when using output prefixes. - Changed test harness to use the HappyDoc class directly instead of calling out to a separate program. - Output a oneliner for referenced pre-formatted documents. - Modified parseinfo.py to improve speed - Expanded information extracted about exceptions thrown by functions - Simplified the regressino test to make it faster by removing Zope docs from the default regression test suite Download Download the latest version of HappyDoc from the home page on SourceForge: http://sourceforge.net/projects/happydoc Doc-string Format How does an author write documentation so that it will be marked up and look fancy? This is a perennial question for Python, and seems to have introduced a roadblock into the development of more robust and useful documentation tools. By separating the formatter classes from the docset classes, HappyDoc allows a user to create their own formatter to interpret comments in any way they see fit. The default for the HTMLTableFormatter (the default formatter for HappyDoc) is to treat __doc__ strings as StructuredText. Don't like StructuredText? Write your own formatter that does something different and drop it into place. Documentation not in Doc-strings It is not always desirable to put all documentation in __doc__ strings. Sometime, notably when working with Zope, special meaning is attached to the presence of __doc__ strings. For this reason, and to support existing code which might not have __doc__ strings, HappyDoc will find and extract documentation in Python comments. Comment documentation can contain all of the same formatting as __doc__ strings. The preceding comment marker will be stripped off and the lines will be assembled and treated as a block of StructuredText. To use this feature, it is important to place the comments **before** the named object which they describe. In this example: # # Class documentation goes here # class ClassWithNoDocStrings: "Using __doc__ strings overrides comment documentation." def method1(self, params): "This method uses a __doc__ string." pass # # Method2 does not use a __doc__ string. # def method2(self): pass The output would include the __doc__ strings for the class and for method1. It would also make it appear that method2 had a __doc__ string with the contents "Method2 does not use a __doc__ string."

1 0

Python 2.1b2 SRPM (was: Re: Python 2.1b2 released)
by Sean Reifschneider March 24, 2001

March 24, 2001

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". I've just put up an SRPM of the 2.1b2 release at: ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/ Again, this one builds the executable as "python2.1", and can be installed along-side your normal Python on the system. Want to check out a great new feature? Type "python2.1 /usr/bin/pydoc string". 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 python-2.1b2-1tummy.src.rpm rpm -i /usr/src/redhat/RPMS/i386/python*2.1b1-1tummy.i386.rpm Note that this release enables "--with-pymalloc". If you experience problems with modules you use, please report the module and how it can be reproduced so that these issues can be taken care of. Enjoy, Sean -- Total strangers need love, too; and I'm stranger than most. Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

1 0

Python 2.1b2 released
by Guido van Rossum March 23, 2001

March 23, 2001

On time, and with a minimum of fuss, we've released Python 2.1b2. Thanks again to the many developers who contributed! Check it out on the Python website: http://www.python.org/2.1/ or on SourceForge: http://sourceforge.net/project/showfiles.php?group_id=5470&release_id=28334 As it behooves a second beta release, there's no really big news since 2.1b1 was released on March 2: - Bugs fixed and documentation added. There's now an appendix of the Reference Manual documenting nested scopes: http://python.sourceforge.net/devel-docs/ref/futures.html - When nested scopes are enabled by "from __future__ import nested_scopes", this also applies to exec, eval() and execfile(), and into the interactive interpreter (when using -i). - Assignment to the internal global variable __debug__ is now illegal. - unittest.py, a unit testing framework by Steve Purcell (PyUNIT, inspired by JUnit), is now part of the standard library. See the PyUnit webpage for documentation: http://pyunit.sourceforge.net/ Andrew Kuchling has written (and is continuously updating) an extensive overview: What's New in Python 2.1: http://www.amk.ca/python/2.1/ See also the Release notes posted on SourceForge: http://sourceforge.net/project/shownotes.php?release_id=28334 We are planning to make the final release of Python 2.1 on April 13; we may release a release candidate a week earlier. We're also planning a bugfix release for Python 2.0, dubbed 2.0.1; we don't have a release schedule for this yet. We could use a volunteer to act as the bug release manager! --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

[ANN] Mahogany 0.62 release
by Vadim Zeitlin March 23, 2001

March 23, 2001

A new release of the `Mahogany' e-Mail and News client has been made. ===================================================================== Source and binaries for a variety of Linux and Unix systems as well as binaries for Win32 are available at http://sourceforge.net/project/showfiles.php?group_id=3100 You can also get to the download page starting from http://mahogany.sourceforge.net/ NB: My sincere excuses to all people who have written me asking for Win32 binaries and to whom I couldn't reply because there were so many of them. For personal reasons I couldn't make the Win32 version as soon as I hoped to. In this message: 1. Announcing Mahogany Version 0.62 2. Changes Against the Previous Release Announcing Mahogany Version 0.62 ===================================================================== Mahogany is an OpenSource(TM) cross-platform mail and news client. It is available for X11/Unix and MS Windows platforms, supporting a wide range of protocols and standards, including POP3, IMAP4 and full MIME support as well as secure communications via SSL. Mahogany can be extended far beyond its original functionality using its built-in Python interpreter and/or its loadable modules (plug-ins). Mahogany's wealth of features and ease of use make it one of the most powerful clients available, providing a consistent and intuitive interface across all supported platforms and an ideal GUI email client for advanced and novice users alike. Mahogany includes an extendable address book system supporting hierarchical organisation of entries, group aliases, searching the database and easy editing, with support for other programs' address database formats. Currently Mahogany's native format, (X)Emacs' BBDB address books and PalmOS address books are supported. LDAP support is planned for future versions. Mahogany is written using the OpenSource wxWindows application framework for GUI C++ applications, building on the GTK+ toolkit on Unix and native Win32 API under Windows and imap-2000 (c-client) library developed by University of Washington for mail folder access. Mahogany is constantly being tested on a variety of Linux systems, Solaris-sparc and MS Windows. It should compile and work on any modern Unix platform. Changes Since Release 0.60 ===================================================================== Key changes are: - fixes to several fatal crashes with IMAP servers - significant speed up of some operations (although more optimizations are to come) - availability of Win32 version - Mahogany is now dual licensed under its Artistic License and GPL New features: - support for marking message as flagged/important - "Extract all addresses from message" command - possibility to import all MBOX folders under the given directory - possibility to set a hard limit for number of messages retrieved from a (remote) folder Improvements: - folders in the tree can now be rearranged, system folders are at top by default - messages can now be sorted by status and by size as well - title and status bar of folder view are customizable strings which can include information about the number of new/unread/flagged messages - show filtering progress in the status bar - filters dialog is now more convenient to use - new mail reporting was made less intrusive Bug fixes: - reading newsgroups doesn't crash the program immediately - parsing of complex MIME structures fixed - language autodetection fixed - fixed crash when viewing messages with wrong date Please see the CHANGES file in the distribution for an even more detailed list of changes. Future Plans ===================================================================== Next, we hope to tackle the following: - improving the message editor (work in progress) - full HTML message editing/displaying (almost complete) - multi-threading to allow network operations to happen in background - PGP/GPG support - LDAP support Please direct any queries to mahogany-developers(a)lists.sourceforge.net and don't hesitate to contact us if you would like to participate in Mahogany development! Known bugs: ----------- *** Please note that Mahogany/UNIX is officially in beta state while *** Mahogany/Win32 is still considered to be in alpha stage (although *** we use both versions on the daily basis). There are always some, listed on our bugtracker at http://mahogany.sourceforge.net/bugz/ and we are working on them. Hoping you will find Mahogany useful, M dev-team

1 0

MS SQL 2000 / HTTP / XML db module
by Luke Kenneth Casson Leighton March 22, 2001

March 22, 2001

python HTTP / XML MS-SQL 2000 database access - v0.1 released. http://sourceforge.net/projects/pyxsqmll (damn, even i have trouble spelling it. stupid name. whoever picked that?? :) version 0.1 uses HTTP Basic Authentication. Your Microsoft SQL 2000 and IIS Server can be configured to require user / password access. btw, the htmlxmlsql2000 module has exactly the same format as MySQLdb 0.3.0 (with a couple of features and functions removed, because i was in a hurry to get this working!) in other words, other than the differences in the SQL statement interoperability (such as SELECT IDENT_CURRENT('tablename') instead of SELECT LAST_INSERT_ID()), you can replace the module name MySQLdb in your code with the module name httpxmlsql2000db and expect it to work. dependencies: - py-xml-0.6.4 (0.6.2 is known to work, too) - python 2.0 (other versions not tested) - MS SQL 2000 (we didn't bother trying with SQL-7, just upgraded) - MS IIS Server with the SQL-2000 XML isapi component enabled. python r0kz! 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] Article: Using Mix-ins with Python
by Chuck Esterbrook March 21, 2001

March 21, 2001

I am re-announcing this because at the time of the original announcement, it was not known that the article would be online. This announcement includes the new URL: 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. http://noframes.linuxjournal.com/lj-issues/issue84/4540.html 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

EVENT: BayPIGgies mtg Wednesday
by Wesley J. Chun March 20, 2001

March 20, 2001

Subject: ANNOUNCEMENT: BayPIGgies meeting Wednesday The Silicon Valley-San Francisco Bay Area Python Users Group (BayPIGgies.org) is meeting this Wednesday in Mountain View, CA. We will be going over what happened at the Python9 conference. March 21, 2001 Topic: Python9 Conference - News and events from the conference last week in Long Beach - Some of the more interesting papers in the proceedings - Upcoming release of Python 2.1 - Python Software Foundation - Guido's opening keynote: Python Fits Your Brain - Bruce Eckel's closing keynote: Why I Love Python Time and directions available at the website: http://www.baypiggies.org Hope to see some of you there! -wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Silicon Valley-SF Bay Area Python users group: http://baypiggies.org "Core Python Programming", Prentice Hall PTR, December 2000 http://starship.python.net/crew/wesc/cpp/ wesley.j.chun :: wesc(a)baypiggies.org cyberweb.consulting :: silicon.valley, ca http://www.roadkill.com/~wesc/cyberweb/

1 0

PEP 241: Metadata for Python Software Packages
by Andrew Kuchling March 19, 2001

March 19, 2001

PEP: 241 Title: Metadata for Python Software Packages Version: $Revision: 1.6 $ Author: A.M. Kuchling <amk1(a)bigfoot.com> Type: Standards Track Created: 12-Mar-2001 Status: Draft Post-History: 19-Mar-2001 Introduction This PEP describes a mechanism for adding metadata to Python packages. It includes specifics of the field names, and their semantics and usage. Including Metadata in Packages The Distutils 'sdist' command will be modified to extract the metadata fields from the arguments and write them to a file in the generated zipfile or tarball. This file will be named PKG-INFO and will be placed in the top directory of the source distribution (where the README, INSTALL, and other files usually go). Developers may not provide their own PKG-INFO file. The "sdist" command will, if it detects an existing PKG-INFO file, terminate with an appropriate error message. This should prevent confusion caused by the PKG-INFO and setup.py files being out of sync. The PKG-INFO file format is a single set of RFC-822 headers parseable by the rfc822.py module. The field names listed in the following section are used as the header names. There's no extension mechanism in this simple format; the Catalog and Distutils SIGs will aim at getting a more flexible format ready for Python 2.2. Fields This section specifies the names and semantics of each of the supported metadata fields. Fields marked with "(Multiple use)" may be specified multiple times in a single PKG-INFO file. Other fields may only occur once in a PKG-INFO file. Fields marked with "(optional)" are not required to appear in a valid PKG-INFO file, all other fields must be present. Metadata-Version Version of the file format; currently "1.0" is the only legal value here. Example: 'Metadata-Version: 1.0' Name The name of the package. Example: 'Name: BeagleVote' Version A string containing the package's version number. This field should be parseable by one of the Version classes (StrictVersion or LooseVersion) in the distutils.version module. Example: 'Version: 1.0a2' Platform (multiple use) A comma-separated list of platform specifications, summarizing the operating systems supported by the package. The major supported platforms are listed below, but this list is necessarily incomplete. POSIX, MacOS, Windows, BeOS, PalmOS. Binary distributions will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary package was compiled. The semantics of the Supported-Platform are not specified in this PEP. Example: 'Platform: POSIX, Windows' Summary A one-line summary of what the package does. Example: "Summary: A module for collecting votes from beagles." Description (optional) A longer description of the package that can run to several paragraphs. (Software that deals with metadata should not assume any maximum size for this field, though one hopes that people won't include their instruction manual as the long-description.) Example: "Description: This module collects votes from beagles\n in order to determine their electoral wishes.\n Do NOT try to use this module with basset hounds; it makes them grumpy." Keywords (optional) A list of additional keywords to be used to assist searching for the package in a larger catalog. Example: 'Keywords: dog puppy voting election' Home-page (optional) A string containing the URL for the package's home page. Example: 'Home-page: http://www.example.com/~cschultz/bvote/' Author (optional) A string containing at a minimum the author's name. Contact information can also be added, separating each line with newlines. Example: 'Author: C. Schultz Universal Features Syndicate Los Angeles, CA' Author-email A string containing the author's e-mail address. It can contain a name and e-mail address in the legal forms for a RFC-822 'From:' header. It's not optional because cataloging systems can use the e-mail portion of this field as a unique key representing the author. A catalog might provide authors the ability to store their GPG key, personal home page, and other additional metadata *about the author*, and optionally the ability to associate several e-mail addresses with the same person. Author-related metadata fields are not covered by this PEP. Example: 'Author-email: "C. Schultz" <cschultz(a)example.com>' License A string selected from a short list of choices, specifying the license covering the package. Some licenses result in the software being freely redistributable, so packagers and resellers can automatically know that they're free to redistribute the software. Other licenses will require a careful reading by a human to determine the software can be repackaged and resold. The choices are: Artistic, BSD, DFSG, GNU PL, Lesser GNU PL, "MIT/X11", Mozilla PL, "public domain", Python, Qt PL, Zope PL, unknown, nocommercial, nosell, nosource, shareware, other The definitions are: Python Python 1.6 or higher license. Version 1.5.2 and earlier are under the MIT/X11 license. public domain Software is public domain, not copyrighted. unknown Status is not known nocommercial Free private use but commercial use not permitted nosell Free use but distribution for profit by arrangement nosource Freely distributable but no source code shareware Payment is requested if software is used other General category for other non-DFSG licenses Some of these licenses can be interpreted to mean the software is freely redistributable. The list of redistributable licenses is: Artistic, BSD, DFSG, GNU PL, Lesser GNU PL, "MIT/X11", Mozilla PL, "public domain", Python, Qt PL, Zope PL, nosource, shareware Note that being redistributable does not mean a package qualifies as free software, 'nosource' and 'shareware' being examples. Example: 'License: MIT/X11' Copyright This document has been placed in the public domain.

1 0

[Module] sql2dtd module
by David Mertz March 18, 2001

March 18, 2001

sql2dtd module -------------- Convert an SQL query to an XML DTD Convert an SQL query to a DTD that specifies an XML dialect for query results. Possibly useful for automating data flows from RDBMS' to other databases (relational or otherwise at the target). URL: http://gnosis.cx/download/sql2dtd.py Download: http://gnosis.cx/download/sql2dtd.py License: Public Domain Categories: Database, XML David Mertz (mertz(a)gnosis.cx) http://gnosis.cx/publish/ -- <a href="http://gnosis.cx/download/sql2dtd.py">sql2dtd module</a> -- Convert an SQL query to an XML DTD

1 0

[Module] Indexer module
by David Mertz March 18, 2001

March 18, 2001

Indexer module -------------- Create full-text indexes and search them A full-text indexer in Python, that may be used either as a stand-alone utility, or as a module in larger programs (incl. CGI). Creates a persistent word dictionary with occurrence rates of words in files. Matches files containing multiple words in search, with optional ranking of matches. URL: http://gnosis.cx/download/indexer.py Download: http://gnosis.cx/download/indexer.py License: Public Domain Requires: zlib (recommended), xml_pickle (optional) Categories: Python Utilities, CGI Scripts David Mertz (mertz(a)gnosis.cx) http://gnosis.cx/publish/ -- <a href="http://gnosis.cx/download/indexer.py">Indexer module</a> -- Create full-text indexes and search them

1 0

gdchart-py 0.6
by Mike Steed March 16, 2001

March 16, 2001

Hi, Version 0.6 of gdchart-py is available at: http://athani.pair.com/msteed/software/gdchart/ New in this version: annotations, background images, scatter, and support for WBMP images. gdchart-py is a Python interface to GDChart, a library for creating charts and graphs in PNG, JPEG, and GIF format. Visit the GDChart home page to get an idea of what it can do: http://www.fred.net/brv/chart/ The Python interface builds on Win32, Linux, Solaris, HP-UX, and probably other Unices. A pre-build Win32 binary is available at the above URL. The software is free to use and distribute. Regards, Mike Steed

1 0

[Module] Caching
by Ole M.Nielsen March 16, 2001

March 16, 2001

Caching ------- Smart caching of function results This module allows results of Python functions to be made persistent for subsequent rapid retrieval. Functions are intercepted, evaluated and their results are compressed and pickled using cPickle. Subsequent function calls with same arguments are replaced by the cached results. If the function or its arguments have been modified it will be recomputed. Recomputation can also be made dependent on the time stamp of arbitrary files or it can be triggered explicitly. This form of caching is very useful for time consuming functions that are called repetitively, such as database or WEB queries but it will work for any function which returns picklable objects. The following paper describes the caching module (along with some others) in more detail: A Toolbox Approach to Flexible and Efficient Data Mining Ole M. Nielsen, Peter Christen, Markus Hegland, Tatiana Semenova and Timothy Hancock. Accepted for the PAKDD-2001 Conference, Hong Kong, April 2001. Available at ftp://csl.anu.edu.au/pub/dm/papers/pakdd2001.pdf.gz or by emailing Ole.Nielsen(a)bigfoot.com URL: http://csl.anu.edu.au/ml/dm/dm_software.html Download: ftp://csl.anu.edu.au/pub/dm/dmtools/caching.py License: GPL Requires: zlib (recommended but not essential) Categories: Python Utilities Ole M. Nielsen (Ole.Nielsen(a)bigfoot.com) http://www.bigfoot.com/~Ole.Nielsen -- <a href="http://csl.anu.edu.au/ml/dm/dm_software.html">Caching</a> -- Smart caching of function results

1 0

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

March 16, 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 15, 2001

March 15, 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