From Marc.Poinot@onera.fr Mon Jul 2 12:22:58 2001 From: Marc.Poinot@onera.fr (Marc Poinot) Date: Mon, 02 Jul 2001 13:22:58 +0200 Subject: Libre Software Meeting/ Python track Message-ID: The Python Track of Libre Software Meeting will start Wed, July 4th, at 14h00, in Bordeaux, France. We hope to see all European Python users there. Check the final program, within the LSM program, at: http://lsm.abul.org -MP- From gward@python.net Tue Jul 3 20:19:33 2001 From: gward@python.net (Greg Ward) Date: Tue, 3 Jul 2001 15:19:33 -0400 Subject: Important news for Montreal-area Python fans Message-ID: Sorry for the geographical specificity, but this announcement is of such staggering importance to Python fans in and around Montreal, Canada that the minor inconvenience of spreading this message all over the world can be safely ignored. For whatever reason, the Cinémathèque québécoise in Montreal has chosen this month to put on a MONTY PYTHON RETROSPECTIVE. (Perhaps this is in response to the recent "Yet Another Perl Conference" in Montreal.) Yes, that's right: at long last, you can pony up your five bucks and sit in a darkened theatre to watch not one, not two, but THREE back-to-back original episodes of *Monty Python's Flying Circus*. Over and over again -- it looks like they're showing episodes 1, 2, 3, 8, 9, 12, 13, 14, 15, 18, 20, 21, 22, 23, 25, 27, 27, 31, 32, 33, 34, 36, 39, 42 (hmmm), 43, and 45. Plus they're showing all the movies, and a couple of BBC television specials (one from 1979 and one from 1990). The main action is from 11 to 25 July; repeats from 26 to 29 July. Looks like most (all?) shows are at 7pm in Salle Fernand-Seguin. (The Cinématheque is at 335 de Maisonneuve E. in downtown Montreal.) You can get the complete list of shows at http://www.cinematheque.qc.ca/cgi/rechbd.cgi?Mt1=python&FichGab=..%2Fprojection%2Fhtml%2Ffgm.html&Ch1=5&Ch2=3&Ch3=7&Ch4=2&ChT1=14&ChT2=10&Soumission=Rechercher Sociable Montreal-area Pythonistas: contact me if you'd like to get together before or after any showing. Perhaps a Montreal PIG could grow out of this auspicious occasion... Greg -- Greg Ward - Python bigot gward@python.net http://starship.python.net/~gward/ Question authority! From mwh@python.net Thu Jul 5 11:12:48 2001 From: mwh@python.net (Michael Hudson) Date: Thu, 5 Jul 2001 11:12:48 +0100 (BST) Subject: python-dev summary 2001-06-21 - 2001-07-05 Message-ID: The less typo-ed version! This is a summary of traffic on the python-dev mailing list between June 21 and July 4 (inclusive) 2001. It is intended to inform the wider Python community of ongoing developments. To comment, just post to python-list@python.org or comp.lang.python in the usual way. Give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration) All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on a PEP if you have an opinion. This is the eleventh summary written by Michael Hudson. Summaries are archived at: Posting distribution (with apologies to mbm) Number of articles in summary: 252 40 | [|] | [|] | [|] | [|] | [|] 30 | [|] | [|] | [|] [|] [|] | [|] [|] [|] [|] | [|] [|] [|] [|] 20 | [|] [|] [|] [|] | [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] 0 +-004-019-007-016-042-018-028-013-005-015-016-029-027-013 Thu 21| Sat 23| Mon 25| Wed 27| Fri 29| Sun 01| Tue 03| Fri 22 Sun 24 Tue 26 Thu 28 Sat 30 Mon 02 Wed 04 This will be my last python-dev summary for a while, as I'm going to be mostly away from the internet for the summer. However, Andrew Kuchling has agreed to take up writing them again, so there should be no interruption in the summaries. * Support for "wide" Unicode characters * Paul Prescod posted a draft of PEP 261 'Support for "wide" Unicode characters': which proposes adding a compile time option to configure unicode objects to store "code points" (the integers that the unicode specification maps to "characters" -- though that word is dangerously overlodaed in the Unicode arena) in 32 bit integers -- they're currently stored in 16 bits. This was (I believe) at least partially inspired by the Unicode Consortium assigning code points outside the "Basic Multilingual Plane" (i.e. the range of 16 bit integers). Noone is convinced that this is the best possible solution (a better solution might be to have unicode objects that could either store code points in 16 bits or 32 bits as necessary, and this solution could have binary compatibility problems), but it seems noone has the time to implement a better one (and a better one would probably have compatibility problems that couldn't be fixed by a simple recompile): (I apologise for any abuse of terminology in the above - I know very little about the issues surrounding Unicode). * Python specializing compiler * Armin Rigo announced his "Python specializing compiler", psyco: It works on the principle that you can compile a faster version of a function if you know stuff about the arguments it's likely to be called with. This is one of the more asthetically pleasing of the possible ways to speed Python up (it's similar to some tactics used by the seemingly defunct self compiler), but it's still a very large amount of work away from being useful... * IPv6 * *Very* preliminary support for IPv6 - the "next generation internet protocol" was checked in. The support thus far doesn't actually support IPv6 at all, but rather emulates IPv6's new functions for IPv4 addresses, so that code for Python 2.2 will hopefully be portable between machines that do and do not support IPv6, whilst being able to use IPv6 where it is supported (I hope that makes sense). Unfortunately the checkin broke the build on some platforms (OSF1, Windows) but I believe these problems are now sorted out. IPv6 support has been muttered about for years now, so it's nice to finally see some movement, even if it is causing some x-platform pain. * PEP 260: simplifying xrange * Guido posted PEP 260, a proposal to removed some of the less useful aspects of the xrange type: Support was muted; there's the usual concern on removing "little used" features -- what if someone (who maybe doesn't read comp.lang.python or these summaries) uses them? * site-python, site-packages * Gregor Hoffleit posted a request that /lib/site-python be considered a standard install target: as the current standard of /lib/pythonX.X/site-packages/ makes life awkward for packagers. It's possible Gregor asked the wrong bunch of people; a non-version dependent path makes life awkward for those who want to mantain more than version of Python, and that includes most of the people on pyton-dev. OTOH, it probably also includes everyone who cares about the cross-version portability of the code they write, so it seems that movemnet is unlikely here (could be wrong, though). Cheers, M. From jason-dated-995052112.13e40c@mastaler.com Thu Jul 5 20:21:51 2001 From: jason-dated-995052112.13e40c@mastaler.com (Jason R. Mastaler) Date: Thu, 05 Jul 2001 13:21:51 -0600 Subject: [ANNOUNCE] TMDA 0.22 - A qmail-based anti-SPAM system Message-ID: Since I announced TMDA 0.10 here a couple months ago, the software has undergone several major feature additions including: * Support for site-wide installations using qmail-relay rewriting. This also allows TMDA to be used by non-qmail clients such as those running Microsoft Windows. * A powerful new matching syntax based on Unix shell-style wildcards. * Package installation options for Linux and FreeBSD. TMDA has also reached a level of stability where I feel it is now production-worthy. About TMDA: TMDA is an OSI certified Python application for qmail systems designed to significantly reduce (or eliminate) the amount of SPAM/UCE you receive by using unique, cryptographically enhanced (called tagged) e-mail addresses. TMDA can both filter your incoming e-mail, and tag your outgoing address. For more information, download locations, and installation instructions, visit the TMDA homepage: Enjoy, Jason R. Mastaler

TMDA 0.22 - A qmail-based anti-SPAM system. (05-Jul-2001) From bh@intevation.de Thu Jul 5 20:34:45 2001 From: bh@intevation.de (Bernhard Herzog) Date: 05 Jul 2001 21:34:45 +0200 Subject: Sketch 0.6.12 - A vector drawing program Message-ID: Sketch 0.6.12 - A vector drawing program Sketch is a vector drawing program for Linux and other unices. It's intended to be a flexible and powerful tool for illustrations, diagrams and other purposes. It has advanced features like gradients, text along a path and clip masks and is fully scriptable due to its implementation in a combination of Python and C. More information, sources and binaries are available at the website: http://sketch.sourceforge.net/ Changes: This new release is just a bug fix release, but since some of the bugs have been introduced in recent Sketch versions, users of 0.6.10 and 0.6.11 should probably upgrade. From recall@metaslash.com Mon Jul 9 02:35:44 2001 From: recall@metaslash.com (Eric C. Newton) Date: Sun, 8 Jul 2001 21:35:44 -0400 Subject: Recall 1.3 Message-ID: Recall 1.3 has been released. Recall is a framework for building distributed, fault-tolerant, replicated storage servers. Recall uses omniORBpy for distributed communications and standardized interfaces. Recall provides high consistency guarantees, the ability to add and remove replicas at run-time, and service during server recovery. There's a graphical demonstration, a line-by-line HOWTO, and several simple examples. It is now possible to build your own fault-tolerant server in 50 lines of code. Recall has been tested under Linux (RedHat 7.1) and Windows 9x with omniORBpy 1.4 and Python 2.1 and Python 1.5. Get it at: http://recall.sourceforge.net Changes: Win32 support. Python 1.5 testing. Additional extensibility hooks. Contact: recall@metaslash.com From eric@isogen.com Mon Jul 9 14:53:55 2001 From: eric@isogen.com (Eric Freese) Date: Mon, 9 Jul 2001 08:53:55 -0500 Subject: ANNOUNCE: SemanText 0.72 released Message-ID: The 0.72 release of SemanText has just been posted at www.semantext.com. Among the new features are: * Context-based harvesting - This allows topics and associations to be automatically constructed from XML documents by identifying specific information to be harvested. * Full topic map maintenance capability - Topics, associations, occurrences, and facets can be added, modified and deleted via the SemanText interface. * Choice of look-and-feel - A classic web browser style of interface or a push-button style of interface. * Choice of view - Users can select whether to look at the information from a topic map point of view (only the information contained in the topic map) or a knowledge base point of view (information based on interpretting the topic map or generated by the inference rules). * XTM export - Topic maps can be exported in accordance with the new XTM specification. About SemanText SemanText is a prototype application developed, using Python, to demonstrate how the topic map standard (ISO/IEC 13250:2000) and XML Topic Maps (XTM) can be used to represent the knowledge contained within documents by building semantic networks. Semantic networks are a building block for artificial intelligence applications such as inference engines and expert systems. From alank@algintech.com Mon Jul 9 17:55:06 2001 From: alank@algintech.com (Alan Klietz) Date: Mon, 9 Jul 2001 11:55:06 -0500 Subject: typo.py - Warn of typographical errors in Python scripts Message-ID: One of the most common annoyances with using Python is that it does not report typographical errors in variable names at compile time. For example, def compute_area(width, height): area = width * hieght # oops Another example is a typo in an attribute for a class, class Square: def __init__(self, width, height): self.width = width self.hieght = height # oops def compute_area(self): return self.width * self.height typo.py will catch these errors and report them: hieght might be used before set at line 2 self.height might be undefined at line 7 You can download typo.py from http://utools.com/typo.htm Alan Klietz Algin Technology alank@algintech.NOSPAM.com From michael@stroeder.com Mon Jul 9 22:25:32 2001 From: michael@stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 09 Jul 2001 23:25:32 +0200 Subject: PyWebLib 1.0.2 Message-ID: HI! I'd like to announce PyWebLib 1.0.2. You can find it on: http://www.stroeder.com/pylib/PyWebLib/ But be warned that documentation is very sparse (some short examples and pydoc-generated HTML). Ciao, Michael. Changes since 1.0.1 - Cleaned up and extended regex handling in pyweblib.forms.Field() - Cleaned up some minor issues found by PyChecker - Fix for non-existent dict keys in pyweblib.session.WebSession._crosscheckSessionEnv() - Modified error handling in pyweblib.session.WebSession._generateSessionID() - other minor fixes - __doc__ strings From knight@baldmt.com Wed Jul 11 23:44:58 2001 From: knight@baldmt.com (Steven Knight) Date: Wed, 11 Jul 2001 17:44:58 -0500 (CDT) Subject: SCons (Python build tool) development under way Message-ID: This is to announce that active development of SCons is now underway at: http://scons.sourceforge.net/ SCons is a Python software construction (or software build) tool. SCons is implemented as a Python script around a central set of Python build-engine modules. SCons configuration files are actually executed as Python scripts, allowing you to use full Python functionality to control your build. You use Python functions and methods in the configuration files to tell the central build engine about your input and output files. Other key features: Dependency calculations are done using MD5 signatures, yielding more reliable builds than timestamp-based dependency analysis. Most dependencies are handled automatically. Building multiple targets in parallel (-j) is supported. It's easy to add your own Builder objects and otherwise customize your build. SCons is still on its way to alpha release, so there's no official package available for download at the moment--sorry. Much of the infrastructure has been coded, though, and is available for anonymous CVS checkout, or browsable via the CVS web interface under the SCons project page at SourceForge: http://sourceforge.net/projects/scons/ The usual set of mailing lists (scons-announce, scons-devel, scons-users) has been created. A small development team (n == 3) is working towards finishing enough documentation and basic functionality for a rapid series of alpha releases in the (hopefully) near future. To help that effort, we'd like to become larger than just a "small" team. If you're interested in contributing, we'd love to hear from you. Check out the developer guidelines on the SCons web site. Yes, SCons is the direct descendant of the ScCons design that won the Software Carpentry build tool competition last year. It's been renamed (dropped the extra 'c') to make it slightly easier to type, and to try to reflect weakly the fact that this project is no longer directly related to Software Carpentry. (Sorry, I don't know the current status of Software Carpentry or the other tools they were planning.) The SCons design is based on the design of the Perl-based Cons software construction tool: http://www.dsmit.com/cons/ SCons improves on the Cons architecture by incorporating several years of practical experience with its strengths and weaknesses. (And, of course, by being written in Python... :-) --SK From gritsch@iue.tuwien.ac.at Thu Jul 12 07:46:43 2001 From: gritsch@iue.tuwien.ac.at (Markus Gritsch) Date: Thu, 12 Jul 2001 08:46:43 +0200 Subject: ANN: VideoCapture 0.4 released Message-ID: VideoCapture-0.4 ================ URL: ---- http://stud4.tuwien.ac.at/~e9326522/VideoCapture/ What it is: ----------- VideoCapture is a Python extension for Win32 which makes it possible to access video-capture devices (e.g. a USB webcam). What is new in version 0.4: --------------------------- *) Added a PyQt based program which periodically retrieves a picture from the web and displays it in a GUI window. A stand-alone binary is temporaly available at http://in1.iue.tuwien.ac.at/temp/webcam-watcher.zip *) Several enhancements to webcam-uploader. Now also a HTML file which displays the uploaded image and periodically reloads itself is placed together with the image on the WebServer. Contact: -------- Markus Gritsch (gritsch@iue.tuwien.ac.at) Enjoy and have fun! From djc@object-craft.com.au Thu Jul 12 15:10:42 2001 From: djc@object-craft.com.au (Dave Cole) Date: 13 Jul 2001 00:10:42 +1000 Subject: csv-0.4 (John Machin release) released In-Reply-To: Dave Cole's message of "17 Jun 2001 23:32:01 +1000" Message-ID: The CSV module provides a fast CSV parser which can split and join CSV records which have been produced by Microsoft products such as Access and Excel. For some reason on Python 2.0, it now outperforms string.split(). Of course the CSV parser can handle much more complex records than string.split()... This is a bugfix release. My thanks to Skip Montanaro for providing most of the following example: CSV files can be syntactically more complex than simply inserting commas between fields. For example, if a field contains a comma, it must be quoted: 1,2,3,"I think, therefore I am",5,6 The fields returned by this example are: ['1', '2', '3', 'I think, therefore I am', '5', '6'] Since fields are quoted using quotation marks, you also need a way to escape them. In Microsoft created CSV files this is done by doubling them: 1,2,3,"""I see,"" said the blind man","as he picked up his hammer and saw" Excel and Access quite reasonably allow you to place newlines in cell and column data. When this is exported as CSV data the output file contains fields with embedded newlines. 1,2,3,"""I see,"" said the blind man","as he picked up his hammer and saw" A single record is split over three lines with text fields containing embedded newlines. This is what happens when you pass that data line by line to the CSV parser. ferret:/home/djc% python Python 2.0 (#0, Apr 14 2001, 21:24:22) [GCC 2.95.3 20010219 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import csv >>> p = csv.parser() >>> p.parse('1,2,3,"""I see,""') >>> p.parse('said the blind man","as he picked up his') >>> p.parse('hammer and saw"') ['1', '2', '3', '"I see,"\012said the blind man', 'as he picked up his\012hammer and saw'] Note that the parser only returns a list of fields when the record is complete. The changes in this release are: 1- Exception raising was leaking the error message. Thanks to John Machin for fixing this. 2- When a parsing exception is raised during parse(), the parser will automatically call clear() discard accumulated fields and state the next time you call parse(). The old behaviour can be restored either by passing zero as the auto_clear constructor keyword argument, or by setting the auto_clear parser attribute to zero. As well as raising an exception, a parsing error will also set the readonly parser attribute had_parse_error to 1. This is reset next time you call parse() or clear(). Thanks again to John Machin for suggesting this. 3- An obscure parsing bug has been fixed. The old behaviour: >>> p.parse('12,12,1",') ['12', '12', '1",'] >>> The new behaviour: >>> p.parse('12,12,1",') ['12', '12', '1"', ''] >>> I am still of two minds about whether I should raise an exception when I encounter text like that... The module homepage: http://www.object-craft.com.au/projects/csv/ For people who do not have a C compiler on Windows I have put a Python 2.1 binary up here: http://www.object-craft.com.au/projects/csv/csv.pyd - Dave -- http://www.object-craft.com.au From robin@alldunn.com Thu Jul 12 18:09:39 2001 From: robin@alldunn.com (Robin Dunn) Date: Thu, 12 Jul 2001 10:09:39 -0700 Subject: wxPython 2.3.1 Message-ID: Hi All, I've finally gotten the 2.3.1 release of wxPython done and ready to go. You can download source and binaries from the website, or directly from Sourceforge. http://wxpython.org/download.php http://sourceforge.net/project/showfiles.php?group_id=10718 If you are using the Linux RPMs please be sure to read the notes on the download page right under the links to the RPMs. Changes in this release are: Added EVT_GRID_EDITOR_CREATED and wxGridEditorCreatedEvent so the user code can get access to the edit control when it is created, (to push on a custom event handler for example.) Added wxTextAttr class and SetStyle, SetDefaultStyle and GetDefaultStyle methods to wxTextCtrl. Added ability to use xml resource files. Still need to add ability to subclass wxXmlResourceHandler, etc... Added wxGridAutoEditMixin to the mixins library package. Made ColourSelect be derived from wxButton. Fixed img2py to work correctly with Python 2.1. Added enhanced wxVTKRenderWindow by Prabhu Ramachandran -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython! From mal@lemburg.com Thu Jul 12 19:55:55 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 12 Jul 2001 20:55:55 +0200 Subject: ANN: eGenix.com mx BASE Extension Package 2.0.2 Message-ID: ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.2 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an open-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms, e.g. you can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platforms independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packaging scheme was reworked, Cygwin support was added and a few subpackages were updated to better support Python 2.1's new coercion mechanism. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1 has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.lemburg.com/files/python/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE packages come with a Python 2.0 style license, which means that you can use them in both commercial and non-commercial settings without fee or charge. All packages come 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:

eGenix.com mx BASE Extension Package 2.0.2 - eGenix.com mx BASE Extension Package 2.0.2 with precompiled binaries for Windows and Linux. (12-Jul-2001) ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 12 19:56:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 12 Jul 2001 20:56:01 +0200 Subject: ANN: eGenix.com mx COMMERCIAL Extension Package 2.0.3 Message-ID: ________________________________________________________________________ ANNOUNCING: eGenix.com mx COMMERCIAL Extension Package for Python Version 2.0.3 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx COMMERCIAL 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. This commercial package includes the popular mxODBC extension which allows users to connect to just about any database on the market today from Windows and Unix. By providing a consistent interface on all supported platforms, it provides a perfect base for writing cross-platform database programs and utilities. ________________________________________________________________________ WHAT'S NEW ? The mxODBC documentation now also includes details on how to write products using mxODBC which are then wrapped into standalone applications using Thomas Heller's py2exe utility. The RPM packaging scheme was reworked and Cygwin support was added. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ 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 places a moderate fee on commercial users. Special licensing setups are available for commercial product developers. 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:

eGenix.com mx COMMERCIAL Package 2.0.3 - eGenix.com mx COMMERCIAL Interface 2.0.3 with distutils support and precompiled binaries for Windows and Linux. (12-Jul-2001) ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Thu Jul 12 19:56:05 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 12 Jul 2001 20:56:05 +0200 Subject: ANN: eGenix.com mx EXPERIMENTAL Extension Package 0.3.0 Message-ID: ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.3.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx EXPERIMENTAL Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an open-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? The mxNumber package was updated to better integrate the provided number types with Python's builtin types. In addition to providing more coercion paths, the integer object in mxNumber has also grown a whole set of useful methods. And last, not least, there's a web-page for mxNumber which provide some details about the new types. It is still far from being complete, but provides some good starting points for those living on the bleading edge. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python long only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.lemburg.com/files/python/ ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package come with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? There currently is no support for these packages, since they are still in alpha or beta. Feedback is welcome, though, so don't hesitate to write us about the quirks you find. ________________________________________________________________________ REFERENCE:

eGenix.com mx EXPERIMENTAL Extension Package 0.3.0 - eGenix.com mx EXPERIMENTAL Extension Package 0.3.0 with precompiled binaries for Windows and Linux. (12-Jul-2001) ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From guido@digicool.com Fri Jul 13 18:21:42 2001 From: guido@digicool.com (Guido van Rossum) Date: Fri, 13 Jul 2001 13:21:42 -0400 Subject: Python 2.1.1c1 released Message-ID: I'm happy to announce the release today of Python 2.1.1c1, a release candidate for Python 2.1.1: http://www.python.org/2.1.1/ This is a pure bugfix release; see the website for details. One fixed "bug" deserves special attention: this release is GPL-compatible. I hope it's in time for inclusion in the Debian release. Thanks to Thomas Wouters for all his work on making this a perfect candidate, despite today's date. :-) The final 2.1.1 release is expected a week from now. Enjoy! --Guido van Rossum (home page: http://www.python.org/~guido/) From x@vex.net Wed Jul 11 01:02:58 2001 From: x@vex.net (Parnassus Submission) Date: Tue, 10 Jul 2001 20:02:58 -0400 (EDT) Subject: [Application] Scribbler Message-ID: Scribbler --------- quick, easy, minimalistic diary script Usage: scribbler.py - edit today's diary entry scribbler.py -b - browse old entries Uses vim to edit and lynx to browse. URL: http://silmarill.org/scribbler.py License: GPL Platform: linux Requires: vim, lynx (can be changed) Categories: Miscellany andrei kulakov -- Scribbler -- quick, easy, minimalistic diary script From cer@tutopia.com Sat Jul 14 20:12:38 2001 From: cer@tutopia.com (Cristian Echeverria) Date: Sat, 14 Jul 2001 15:12:38 -0400 Subject: ANN: Python News in Spanish - Noticias de Python en Español Message-ID: ANNOUNCING WEBSITE: Python News in Spanish: This site is similar (I hope) to pythonware Daily Python-URL (http://www.pythonware.com/daily/), but in spanish. ANUNCIANDO SITIO: Noticias de Python en Español A partir de este momento se encuentra en operaciones este sitio, que pretende mantener informado a todos los de habla hispana respecto de las últimas novedades de Python y sus distintas librerías. La página principal es http://www.chevenet.com. Esta página pretende ser similar al Daily Python-URL disponible a través de pythonware y de hecho utiliza la misma tecnología de publicación. Desde ya hago el llamado a todos los interesados en cooperar con contenidos a esta página para que se comuniquen a: cristian_echeverria@yahoo.com Además de las noticias tengo la intención de incorporar una sección con vínculos y otra con artículos tutoriales. Cristian Echeverría http://www.chevenet.com From asl2@pobox.com Fri Jul 13 21:43:35 2001 From: asl2@pobox.com (Aaron Lav) Date: Fri, 13 Jul 2001 16:43:35 -0400 (EDT) Subject: [Module] PyZ3950 Message-ID: PyZ3950 ------- Z39.50 client and server, and ASN.1 BER PyZ3950 includes an ASN.1 BER encoding/decoding package designed to be reasonably general and reusable in other contexts, and an alpha-quality Z39.50 client and server implementing v2 Init, Search, Present, and Close PDUs. URL: http://www.pobox.com/~asl2/software/PyZ3950 License: BSD Style Categories: Internet Aaron Lav (asl2@pobox.com) http://www.pobox.com/~asl2 -- PyZ3950 -- Z39.50 client and server, and ASN.1 BER From foo@ix.netcom.com Sat Jul 14 09:52:36 2001 From: foo@ix.netcom.com (Matt Butler) Date: Sat, 14 Jul 2001 04:52:36 -0400 (EDT) Subject: [Module] hackicon 0.0003 Message-ID: hackicon 0.0003 --------------- Change the Tk icon on win32 Hackicon allows you to change the red "Tk" icon that appears on a Toplevel widget in Tkinter on win32. I spent many hours trying to find a solution (without adding a major new dependency like win32all) to this simple problem. I couldn't so I hacked one up. If there is a solution to this problem already and I missed it... . Version: 0.0003 Initial Release Python Versions: 2.0 2.1 License: LGPL Author: Matt Butler foo@ix.netcom.com URL: http://hackicon.sourceforge.net Download: http://prdownloads.sourceforge.net/hackicon/hackicon00003.zip License: LGPL Platform: win32 Binaries: http://prdownloads.sourceforge.net/hackicon/hackicon00003.zip Gui: Tkinter Categories: GUI Matt Butler (foo@ix.netcom.com) http://www.netcom.com/~foo -- hackicon 0.0003 -- Change the Tk icon on win32 From PyChecker Tue Jul 17 03:23:26 2001 From: PyChecker (Neal Norwitz) Date: Mon, 16 Jul 2001 22:23:26 -0400 Subject: ANN: PyChecker version 0.7 Message-ID: A new version of PyChecker is available for your hacking pleasure. PyChecker is a tool for finding common bugs in python source code. It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++. Comments, criticisms, new ideas, and other feedback is welcome. Change Log: * Improve import warning messages, add from ... import ... checks * checker.py -h prints defaults after processing .pycheckrc file * Add config option -k/--pkgimport to disable unused imports from __init__.py * Add warning for variable used before being set * Improve format string checks/warnings * Check arguments to constructors * Check that self is first arg to base constructor * Add -e/--errors option to only warn about likely errors * Make 'self' configurable as the first argument to methods * Add check that there is a c'tor when instantiating an object and passing arguments * Add config option (-N/--initreturn) to turn off warnings when returning None from __init__() * Fix internal error with python 2.1 which defines a new op: LOAD_DEREF * Check in lambda functions for module/variable use * Fix inability to evaluate { 1: 'a' } inline, led to incorrect __init__() not called warnings * Fix exception when class overrides __special__() methods & raise exception * Fix check in format strings when using '%*g %*.*g', etc * Add check for static class attributes * Fix checking of module attributes * Fix wrong filename in 'Base class (xxx) __init__() not called' when doing a from X import * * Fix 'No attribute found' for very dynamic classes (may also work for classes that use __getattr__) PyChecker is available on Source Forge: Web page: http://pychecker.sourceforge.net/ Project page: http://sourceforge.net/projects/pychecker/ Neal -- pychecker@metaslash.com From Anthony@COMPUTRONIX.com Tue Jul 17 21:37:24 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Tue, 17 Jul 2001 14:37:24 -0600 Subject: cx_Oracle 2.2 Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10F00.49711950 Content-Type: text/plain; charset="iso-8859-1" I am pleased to announce a new version of cx_Oracle, a Python DB-API 2.0 compliant interface module. The changes are as follows.... Changes from 2.1 to 2.2 1) Upgraded thread safety to level 1 (according to the Python DB API 2.0) as an internal project required the ability to share the module between threads. 2) Added ability to bind ref cursors to PL/SQL blocks as requested by Brad Powell. 3) Added function write(Value, [Offset]) to LOB variables as requested by Matthias Kirst. 4) Procedure execute() on Cursor objects now permits a value None for the statement which means that the previously prepared statement will be executed and any input sizes set earlier will be retained. This was done to improve the performance of scripts that execute one statement many times. 5) Modified module global constants BINARY and DATETIME to point to the external representations of those types so that the expression type(var) == cx_Oracle.DATETIME will work as expected. 6) Added global constant version to provide means of determining the current version of the module. 7) Modified error checking routine to distinguish between an Oracle error and invalid handles. 8) Added error checking to avoid setting the value of a bind variable to a value that it cannot support and raised an exception to indicate this fact. 9) Added extra compile arguments for the AIX platform as suggested by Jehwan Ryu. 10) Added section to the README to indicate the method for a binary installation as suggested by Steve Holden. 11) Added simple usage example as requested by many people. 12) Added HISTORY file to the distribution. If there are any comments please feel free to write to me at anthony@computronix.com. Thanks. Anthony Tuininga ------_=_NextPart_001_01C10F00.49711950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable cx_Oracle 2.2

I am pleased to announce a new version = of cx_Oracle, a Python DB-API 2.0 compliant interface module. The = changes are as follows....

Changes from 2.1 to 2.2

 1) Upgraded thread safety to = level 1 (according to the Python DB API 2.0) as
    an internal = project required the ability to share the module between
    threads.
 2) Added ability to bind ref = cursors to PL/SQL blocks as requested by
    Brad = Powell.
 3) Added function write(Value, = [Offset]) to LOB variables as requested by
    Matthias = Kirst.
 4) Procedure execute() on = Cursor objects now permits a value None for the
    statement which = means that the previously prepared statement will be
    executed and any = input sizes set earlier will be retained. This was done to
    improve the = performance of scripts that execute one statement many times.
 5) Modified module global = constants BINARY and DATETIME to point to the
    external = representations of those types so that the expression
    type(var) =3D=3D = cx_Oracle.DATETIME will work as expected.
 6) Added global constant = version to provide means of determining the current
    version of the = module.
 7) Modified error checking = routine to distinguish between an Oracle error and
    invalid = handles.
 8) Added error checking to = avoid setting the value of a bind variable to a
    value that it = cannot support and raised an exception to indicate this fact.
 9) Added extra compile = arguments for the AIX platform as suggested by Jehwan
    Ryu.
10) Added section to the README to = indicate the method for a binary
    installation as = suggested by Steve Holden.
11) Added simple usage example as = requested by many people.
12) Added HISTORY file to the = distribution.

If there are any comments please feel = free to write to me at anthony@computronix.com. Thanks.

Anthony Tuininga

------_=_NextPart_001_01C10F00.49711950-- From djc@object-craft.com.au Wed Jul 18 04:09:33 2001 From: djc@object-craft.com.au (Dave Cole) Date: 18 Jul 2001 13:09:33 +1000 Subject: Sybase module 0.30 (Graham Ashton release) released In-Reply-To: Dave Cole's message of "27 Jun 2001 13:05:27 +1000" Message-ID: What is it: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. This is the first release in which the DB-API compliance is as close as it can get with Sybase. There was a recent thread on comp.lang.python where Python database modules were labelled experimental and unsupported. We have decided to label ours as non-experimental and will be offering commercial support from this release. Please refer to our website for details: http://www.object-craft.com.au/support.html For those people who do not have LaTeX installed, there is a PDF version of the package documentation. The PostScript version prints out a handy A5 booklet on an A4 duplex printer. The module and documentation are all available on here: http://www.object-craft.com.au/projects/sybase/ Thanks ------ Many thanks to Graham Ashton for spending time working with me to isolate the dynamic SQL deallocation bug. Changes for this release ------------------------ Bugfixes: 1) Dynamic SQL constructed for cursor is now deallocated. After around 9000 different queries over the same cursor the server was running out of procedure space. 2) ct_con_props() CS_TDS_VERSION is an integer no a string. 3) ct_con_props(), ct_options(), ct_config() were returning string values with trailing nul character. 4) ct_config() CS_VERSION is an integer no a string. 5) Fixed refcount leak in ct_res_info(CS_ORDERBY_COLS) DB-API compliance: 1) Implemented DB-API STRING, BINARY, NUMBER, DATETIME, and ROWID type objects. 2) Implemented DB-API Date(), Timestamp(), DateFromTicks(), TimestampFromTicks(), and Binary() functions. Documentation: 1) Complete DB-API documentation for Sybase.py 2) Low level sybasect extension module now explains how the Sybase API is wrapped - it does not attempt to explain how to use the API. Sybase have excellent documentation which covers that. Documentation for bulkcopy descriptors includes a small program to bulkcopy a table from one server to another using a single set of buffers. 3) Miscellaneous docstring fixups. Improvements and enhancements: 1) All binary dependence on mxDateTime has been removed - it is now integrated at Python level. If mxDateTime is available then datetime columns will be returned as mxDateTime.DateTime objects - otherwise they are returned as internal DateTime objects. You can disable the use of mxDateTime by doing this: import Sybase Sybase.use_datetime = 0 2) Renamed con object in Sybase.py to conn to be consistent with sybasect wrapper module. 3) Reorganised and simplified cursor DB-API state machine in Sybase.py. 4) Wrap all Sybase API functions with checks for exceptions raised by Python callback functions. 5) Added debug, conn, and direction attributes to CS_BLKDESC object. 6) When CS_DATAFMT structures are cleared when initialised - eliminates possibility of unexpected values. 7) Added native Sybase datetime/smalldatetime object. Construct and use these objects like this: >>> import Sybase >>> a = Sybase.money(25.99) >>> type(a) >>> b = a + 5 >>> b 30.99 >>> type(b) >>> b - a 5.00 >>> dt = Sybase.datetime('2001-07-17', Sybase.CS_DATETIME4_TYPE) >>> dt Jul 17 2001 12:00AM >>> type(dt) 8) Added native Sybase money/smallmoney object. 9) DataBuf objects can autoconvert values to money and numeric values during assignment. -- http://www.object-craft.com.au From Anthony@COMPUTRONIX.com Wed Jul 18 14:21:42 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Wed, 18 Jul 2001 07:21:42 -0600 Subject: cx_Oracle 2.2 Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10F8C.95AAC780 Content-Type: text/plain; charset="iso-8859-1" I am pleased to announce a new version of cx_Oracle, a Python DB-API 2.0 compliant interface module. Download from www.computronix.com/utilities Changes from 2.1 to 2.2 1) Upgraded thread safety to level 1 (according to the Python DB API 2.0) as an internal project required the ability to share the module between threads. 2) Added ability to bind ref cursors to PL/SQL blocks as requested by Brad Powell. 3) Added function write(Value, [Offset]) to LOB variables as requested by Matthias Kirst. 4) Procedure execute() on Cursor objects now permits a value None for the statement which means that the previously prepared statement will be executed and any input sizes set earlier will be retained. This was done to improve the performance of scripts that execute one statement many times. 5) Modified module global constants BINARY and DATETIME to point to the external representations of those types so that the expression type(var) == cx_Oracle.DATETIME will work as expected. 6) Added global constant version to provide means of determining the current version of the module. 7) Modified error checking routine to distinguish between an Oracle error and invalid handles. 8) Added error checking to avoid setting the value of a bind variable to a value that it cannot support and raised an exception to indicate this fact. 9) Added extra compile arguments for the AIX platform as suggested by Jehwan Ryu. 10) Added section to the README to indicate the method for a binary installation as suggested by Steve Holden. 11) Added simple usage example as requested by many people. 12) Added HISTORY file to the distribution. If there are any comments please feel free to write to me at anthony@computronix.com. Thanks. Anthony Tuininga ------_=_NextPart_001_01C10F8C.95AAC780 Content-Type: text/html; charset="iso-8859-1" cx_Oracle 2.2

I am pleased to announce a new version of cx_Oracle, a Python DB-API 2.0 compliant interface module.
Download from www.computronix.com/utilities

Changes from 2.1 to 2.2

 1) Upgraded thread safety to level 1 (according to the Python DB API 2.0) as
    an internal project required the ability to share the module between
    threads.
 2) Added ability to bind ref cursors to PL/SQL blocks as requested by
    Brad Powell.
 3) Added function write(Value, [Offset]) to LOB variables as requested by
    Matthias Kirst.
 4) Procedure execute() on Cursor objects now permits a value None for the
    statement which means that the previously prepared statement will be
    executed and any input sizes set earlier will be retained. This was done to
    improve the performance of scripts that execute one statement many times.
 5) Modified module global constants BINARY and DATETIME to point to the
    external representations of those types so that the expression
    type(var) == cx_Oracle.DATETIME will work as expected.
 6) Added global constant version to provide means of determining the current
    version of the module.
 7) Modified error checking routine to distinguish between an Oracle error and
    invalid handles.
 8) Added error checking to avoid setting the value of a bind variable to a
    value that it cannot support and raised an exception to indicate this fact.
 9) Added extra compile arguments for the AIX platform as suggested by Jehwan
    Ryu.
10) Added section to the README to indicate the method for a binary
    installation as suggested by Steve Holden.
11) Added simple usage example as requested by many people.
12) Added HISTORY file to the distribution.

If there are any comments please feel free to write to me at anthony@computronix.com. Thanks.

Anthony Tuininga


------_=_NextPart_001_01C10F8C.95AAC780-- From guido@digicool.com Wed Jul 18 14:58:56 2001 From: guido@digicool.com (Guido van Rossum) Date: Wed, 18 Jul 2001 09:58:56 -0400 Subject: RELEASED: Python 2.2a1 Message-ID: Are you worried that Python 2.2 will break all your old Python code? Don't be! Help us make Python 2.2 as compatible and stable as any release before it. I've released the first alpha release, Python 2.2a1, for your perusal. Download it from: http://www.python.org/2.2/ Give it a good try, and report what breaks to the bug tracker: http://sourceforge.net/bugs/?group_id=5470 New features in this release include: - *TENTATIVELY*, a new way of introspecting instances of built-in types (PEP 252) and the ability to subclass built-in types (PEP 253) have been added. This falls under the header of "type/class unification". More about this below. - Iterators (PEP 234) and generators (PEP 255) were added. The second PEP adds a new reserved word, "yield", which must be enabled by adding "from __future__ import generators" to the top of every module that uses it. Without that, "yield" is treated as an identifier but a warning is issued. - Fredrik Lundh's xmlrpclib is now a standard library module. This provides full client-side XML-RPC support. For the full list of changes, see the release notes on SourceForge: http://sourceforge.net/project/shownotes.php?release_id=43931 As usual, Andrew Kuchling is writing a gentle introduction to the most important changes (currently excluding type/class unification), titled "What's New in Python 2.2": http://www.amk.ca/python/2.2/ Regarding the changes for type/class unification: these have *TENTATIVE* status. While I've done my best to make them backwards compatible, it's unavoidable that a few things may break. In particular, programs doing introspection (looking inside objects to find out what they are) will find that things have changed. I believe the changes are for the better: for example, you can now find out the methods defined for socket objects, and their docstrings, without actually opening a socket. The purpuse of the alpha cycle is to decide whether to go forward with these changes. It's unlinkely, but possible, that we run into unexpected snags during alpha testing, and I may even have to withdraw the changes completely if we conclude they break too much code and we can't fix it any other way. More likely, the second alpha release will introduce fixes to improve the backwards compatibility. In the mean time, for those of you using the CVS tree, these changes are not checked in on the trunk, but on a branch tagged "descr-branch". I'm writing an introduction to the type/class unification: http://www.python.org/2.2/descrintro.html This currently isn't finished yet, but it already contains a list of the most visible backwards incompatibilities. I hope to complete it this week. Until then, please refer to PEP 252 and PEP 253. These aren't intended as tutorials, but they do have most of the information you might be looking for. Here's the URL for the PEP index: http://www.python.org/peps/ Thanks to everybody who contributed to this release. Special thanks go to Tim Peters, who worked through the night to build the Windows installer using an uncooperative installer maker. Enjoy! --Guido van Rossum (home page: http://www.python.org/~guido/) From bckfnn@worldonline.dk Wed Jul 18 21:45:04 2001 From: bckfnn@worldonline.dk (Finn Bock) Date: Wed, 18 Jul 2001 20:45:04 GMT Subject: ANN: Second alpha release of Jython-2.1 Message-ID: I am happy to announce the second 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 on version 2.1a2 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 display hook A complete list of changes and differences are available here: http://www.jython.org/NEWS.html A list of fixed bugs can be found here: http://sourceforge.net/tracker/?group_id=12867&atid=112867 Change the Status input box to "Closed" and the Group input box to "Fixed in 2.1a2" and press the "Browse" button. Bugs can be reported to the bug manager on SourceForge: http://sourceforge.net/bugs/?group_id=12867 Cheers, the jython-developers From sheila@thinkspot.net Thu Jul 19 06:34:11 2001 From: sheila@thinkspot.net (Sheila King) Date: Wed, 18 Jul 2001 22:34:11 -0700 Subject: [Application] Update: Gypsy Mail 0.6.3 beta Message-ID: Gypsy Mail 0.6.3 beta -------------------- A Form Mail cgi script A Python clone of the well-known cgiemail script, with added features and flexibility. This script allows you to set up an HTML form on your website, to collect information from your site's visitors, and send a very nicely formatted e-mail to yourself, or other e-mail addresses. NEW in version 0.6.2+: custom success page--give a URL to redirect to for your own custom success page. This is a partial implementation of custom success pages. The next release will have the ability to write success page templates, for a completely customizable success page with the look and feel of the rest of your website, and the ability to display as much or as little of the e-mail message as desired. Comes with sample forms and templates. Cross-platform. Under continuing development. I am looking for testers for this script. URL: http://www.thinkspot.net/sheila/computers/software/gypsymail.html Download: http://www.thinkspot.net/sheila/computers/software/gypsy/gypsy063.tar.gz or http://www.thinkspot.net/sheila/computers/software/gypsy/gypsy063.zip License: GPL Categories: CGI Scripts NEW in version 0.6.3 (from the change log): version 0.6.3 beta - 2001.7.18 -corrected misleading and confusing directions in the various files, such as gypsydoc.html and defaultconfig.txt. -stripped out all occurrences of CRLF (carriage-return/line-feed) in the entire message, including headers, to fix problems with Windows linefeeds vs. standard SMTP protocol (hope that this fixes problem in Outlook Express display). version 0.6.2 beta - 2001.7.17 -Partially implemented custom success page. Script can now redirect to any desired URL on the success page. -- Sheila King http://www.thinkspot.net/sheila/ http://www.k12groups.org/ From michael@stroeder.com Fri Jul 20 16:35:32 2001 From: michael@stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 20 Jul 2001 17:35:32 +0200 Subject: PyWebLib 1.0.4 Message-ID: HI! I'd like to announce PyWebLib 1.0.4. You can find it on: http://www.stroeder.com/pylib/PyWebLib/ But be warned that documentation is very sparse (some short examples and pydoc-generated HTML) and the API might be still subject to subtle changes. Ciao, Michael. ------------------------------------------------------------------ 2001-07-19 PyWebLib 1.0.4 - Local var maxContentLength is calculated correctly now in Form.getInputFields() instead of using class attribute Form.maxContentLength. Class attribute Form.maxContentLength was abandoned completely. - Fixed test program cgi-bin/test-session.py to reflect renaming of key word arguments done in 1.0.3 for pyweblib.session.WebSession.__init__() ------------------------------------------------------------------ 2001-07-13 PyWebLib 1.0.3 Changes since 1.0.2 - Cleaned up pyweblib.session.CleanUpThread - Some incompatible renaming of key word arguments of pyweblib.session.WebSession.__init__()! From inigoserna@terra.es Fri Jul 20 17:43:26 2001 From: inigoserna@terra.es (=?ISO-8859-1?Q?I=F1igo?= Serna) Date: 20 Jul 2001 18:43:26 +0200 Subject: ANN: lfm v0.4 Message-ID: Please, forgive me if you recieve this mail two times, I'm having problems with my ISP. I=F1igo ********************************************************************** Hello everybody, I'm very pleased to announce lfm v0.4, the first public release. Last File Manager is a Midnight Commander clone (or Norton Commander for the aged, or Windows Commander for the poor people who have to run windows ;-) written entirely in Python. It runs on any UNIX with Python 2.0 or higher with curses module compiled in. Note that I needed to recompile python with ncurses on Solaris because Solaris curses didn't work properly. Get it from http://www.terra.es/personal7/inigoserna/lfm Lfm is released under GNU License. You can read its features in the web site or in the README file of the package. The program is fairly usable but it isn't finished yet, but as I'm going to take a few days of holidays I've released it now to get comments, suggestions, bug reports, etc. Well, I hope you like it. Best regards, I=F1igo Serna From guido@digicool.com Fri Jul 20 18:03:32 2001 From: guido@digicool.com (Guido van Rossum) Date: Fri, 20 Jul 2001 13:03:32 -0400 Subject: RELEASED: Python 2.1.1 Message-ID: I've released Python 2.1.1 today. This is the final version of this bugfix release for Python 2.1, and should be fully compatible with Python 2.1. There should be *no* reason to use 2.1 any more. Many thanks to Thomas Wouters for being the release manager! Pick up your copy here: http://www.python.org/2.1.1/ Python 2.1.1 is GPL-compatible. This means that it is okay to distribute Python binaries linked with GPL-licensed software; Python itself is not released under the GPL but under a less restrictive license which is Open Source compliant. PS: I've noticed some disarray of mail sent through python.org; this seems to have to do with the dysfunctional ORBS "spam-checker". See http://mail.python.org/pipermail/python-dev/2001-July/016151.html for details. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm@hypernet.com Fri Jul 20 21:55:45 2001 From: gmcm@hypernet.com (Gordon McMillan) Date: Fri, 20 Jul 2001 16:55:45 -0400 Subject: ANN: 3rd beta of Win32 Installer release 4 Message-ID: The thrid beta of version 4 of the Win32 Installer package is here: http://www.mcmillan-inc.com/installer_dnld.html This beta fixes some bugs in package support and dependency analysis (mxDateTIme is working again, PyXML works properly once the package is included). The docs feature a more gentle introduction for those who want to stay away from the complexities. Version 4 handles all Python versions from 1.5 onward (it's been tested with 1.5 and 2.1). It has a number of new capabilities: - set a Windows version resource in the executable (NT / Win2K only), including the ability to create a version resource from Python - a utility to analyze the dependency tree of a script / module (including a cross-reference) - warnings issued when dynamic code encountered (__import__, exec, eval) - COM client support (including using gencache.EnsureModule to generate support on the end-user's machine). What is it? The Installer is a set of tools for distributing Python applications. The target machines do not need to have Python installed, or may have a different version of Python installed. The Windows version (there's a more limited Linux version, too), has top level scripts for 3 configurations: - Standalone: create a single directory installation for your app - Simple: wraps a Standalone with a simple install script - Freeze: creates an executable that unpacks itself at run time, and cleans up afterward. More complex distributions can be created by writing your own config file and passing it to Builder. Old-Python-style license. Contact: gmcm@hypernet.com

Win32 Installer release 4a2 A compiler-less way of distributing Python apps on Windows. (20-July-01) - Gordon From StephenM.Gava Sat Jul 21 15:08:54 2001 From: StephenM.Gava (StephenM.Gava) Date: Sun, 22 Jul 2001 00:08:54 +1000 Subject: Fwd: idlefork - alpha release Message-ID: ---------- Forwarded Message ---------- Subject: idlefork - alpha release Date: Sat, 21 Jul 2001 23:53:55 +1000 From: Stephen M. Gava To: idle-dev@python.org Hello IDLErs, just to let you know there is an alpha release of the current state of IDLEfork now available. This release is primarily to mark the finish of the merge of the current idle cvs back into idlefork. A few things are broken, but if you want to play with it or look at it it is available from the idlefork sourceforge page at: http://sourceforge.net/projects/idlefork Here are the relevant parts of README and NEWS for the new release: IDLEfork README =============== IDLEfork is an official experimental fork of Python's Integrated DeveLopment Environment IDLE. Worthwhile and successful changes and additions will go back into the Python distribution's IDLE at some later stage. There is no spanish inquisition. As David Scherer aptly put it in the original IDLE fork README (below), "It is alpha software and might be unstable. If it breaks, you get to keep both pieces." One of the aims of IDLEfork now is for it to be able to be uncompressed into its own directory and run from there, that way you can play with (or hack on) IDLEfork without any further installation, and entirely separately from your stable python IDLE distribution. If you find bugs or undesired behaviour please code nifty patches and submit them to the IDLEfork SourceForge patch manager, 8^) or let us know about it in one of the appropriate fora. See the IDLEfork home page at http://idlefork.sourceforge.net for details on the various ways to give input to or contact the project. Please see the files NEWS.txt and ChangeLog for more up to date information on changes in this release of IDLEfork. IDLEfork NEWS ============= (For a more detailed change log, see the file ChangeLog.) --------------------------------------------------------- IDLEfork 0.8.1 (22 JUL 2001) ---------------------------- New tarball released as a result of the 'revitalisation' of the IDLEfork project. This release requires python 2.1 or better. Compatability with earlier versions of python (especially ancient ones like 1.5x) is no longer a priority in IDLEfork development. This release is based on a merging of the earlier IDLE fork work with current cvs IDLE (post IDLE version 0.8), with some minor additional coding by Kurt B. Kaiser and Stephen M. Gava. This release is basically functional but also contains some known breakages, particularly with running things from the shell window. Also the debugger is not working, but I believe this was the case with the previous IDLE fork release (0.7.1) as well. This release is being made now to mark the point at which IDLEfork is launching into a new stage of development. IDLEfork CVS will now be branched to enable further development and exploration of the two "execution in a remote process" patches submitted by David Scherer (David's is currently in IDLEfork) and GvR, while stabilisation and development of less heavyweight improvements (like user customisation) can continue on the trunk. Regards, Stephen. -- Stephen M. Gava "More power to those who don't care for it." - anon ------------------------------------------------------- From grahamd@dscpl.com.au Sun Jul 22 08:35:28 2001 From: grahamd@dscpl.com.au (Dumpleton Software Consulting PL) Date: Sun, 22 Jul 2001 01:35:28 -0600 (MDT) Subject: ANN: OSE 7.0b8 now available. Message-ID: OSE 7.0b8 is now available. At its core, OSE is a C++ class library for general purpose programming, but also includes support for building event driven systems and distributed applications using a request/reply and publish/subscribe style service agent framework. The ability to interact with an application is facilitated using a HTTP servlet framework and RPC over HTTP interfaces. In short, OSE could be said to take technology from message oriented middleware, application server and web service technology and wraps it all into one. Although C++ at its core, OSE also provides wrappers for the Python programming language. This mix means that OSE serves as a useful platform for building standalone or distributed applications in Python, C++ or a mix of both. Its support of both XML-RPC and SOAP protocols through a single service interface makes it ideal for building web based services. OSE has included wrappers for Python for over a year, but this is the first time it has been announced to the Python community as time has been allowed for the interfaces to mature. A significant amount of documentation (approx 70 pages) on the Python interfaces has also now been completed. Further information on OSE and the software itself, can be found at: http://ose.sourceforge.net OSE is released under the QPL. This release is the culmination of over 10 years of development, OSE first being available over the Internet in 1993. As an illustration of how web services can be quickly constructed using OSE, here is a simple web service providing the current local time of the host machine. import netsvc import signal class Service(netsvc.Service): def __init__(self,name="clock"): netsvc.Service.__init__(self,name) self.joinGroup("web-services") self.exportMethod(self.time) def time(self): return netsvc.DateTime() dispatcher = netsvc.Dispatcher() dispatcher.monitor(signal.SIGINT) daemon = netsvc.HttpDaemon(8000) gateway = netsvc.RpcGateway("web-services") daemon.attach("/",gateway) daemon.start() dispatcher.run() Additional examples can be found on the OSE web site. The modular manner in which services can be created lends itself to the development of a library of services which can be reused in different applications. It is hoped that over time such a library may be developed allowing for plug and play style application development with quick turn around times. Enjoy. :-) -- Graham Dumpleton (grahamd@dscpl.com.au) From Marc.Poinot@onera.fr Mon Jul 23 09:58:21 2001 From: Marc.Poinot@onera.fr (Marc Poinot) Date: Mon, 23 Jul 2001 10:58:21 +0200 Subject: pyCGNS v0.1 - A Python binding to CGNS Message-ID: This is a very specialized package for Computational Fluid Dynamics. The pyCGNS package is a proposal for a Python binding to the CGNS libraries. These libraries are dedicated to the management of a new Computational Fluid Dynamics database format. The package includes both a wrapper on top of the ADF libraries, and a wrapper on top of the SIDS (or CGNS) libraries. There is a set of tests, demos and a tree parse tool, all written using pyCGNS Python binding. You can also find a little intro doc: pyCGNS-v0.1/Doc/manual.ps This package requires the Numerical Python package. The package will be available on the anonymous ftp, at ONERA: ftp.onera.fr:/incoming/xtmp/pyCGNS/pyCGNS-v0.1.tar.gz It will be avaible for 4 days (sorry, automatic garbage there...) Send me an email if you want the package after this deadline. -MP- ----------------------------------------------------------------------- Marc POINOT Alias: marcvs Email: poinot@onera.fr ONERA -MFE/DSNA/ELSA Tel: 01.46.73.42.84 Info: elsa-info@onera.fr 29, Div. Leclerc Fax: 01.46.73.41.66 Site: 92322 Chatillon FRANCE Project: elsA Web: http://www.onera.fr From barry@zope.com Wed Jul 25 21:06:20 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 25 Jul 2001 16:06:20 -0400 Subject: ANNOUNCE Mailman 2.0.6 Message-ID: I've just released version 2.0.6 of Mailman, the GNU Mailing List Manager. Mailman is released under the GNU General Public License (GPL). Version 2.0.6 fixes a potential security problem in Mailman 2.0.x, and includes a few other minor bug fixes. It is possible, although unlikely, that you could have an empty site password, or an empty list password. Because of peculiarities in the Unix crypt() function, such empty passwords could allow unauthorized access to the list administrative pages with an arbitrary password string. This situation does not occur normally, but it is possible to create it by accident (e.g. by touch'ing data/adm.pw). This patch ensures that such empty passwords do not allow unauthorized access, by first checking to make sure that the salt is at least 2 characters in length. Alternatively, you can make sure that either data/adm.pw does not exist or that it is not empty. For the extra paranoid, you'd need to be sure that none of your lists have empty passwords, but that's an even more difficult situation to create by accident. This patch guards against both situations. (Please note that Mailman 2.1alpha is not vulnerable to this problem because it does not use crypt().) A few other minor bugs have been fixed; see the NEWS excerpt below for details. Mailman 2.0.6 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. 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.6 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 Downloads are available at http://sourceforge.net/project/shownotes.php?release_id=45268 There are email lists (managed by Mailman, of course!) for both Mailman users and developers. See the web sites above for details. Enjoy, -Barry 2.0.6 (25-Jul-2001) Security fix: - Fixed a potential security hole which could allow access to list administrative features by unauthorized users. If there is an empty data/adm.pw file (the site password file), then any password will be accepted as the list administrative password. This exploit is caused by a common "bug" in the crypt() function suffered by several Unix distributions, including at least GNU/Linux and Solaris. Given a salt string of length zero, crypt() always returns the empty string. In lieu of applying this patch, sites can run bin/mmsitepass and ensure that data/adm.pw is of length 2 or greater. Bug fixes: - Ensure that even if DEFAULT_URL is misconfigured in mm_cfg.py (i.e. is missing a trailing slash), it is always fixed upon list creation. - Check for administrivia holds before any other tests. - SF bugs fixed: 407666, 227694 - Other miscellaneous buglets fixed. From jon-sven@frisurf.no Thu Jul 26 00:38:50 2001 From: jon-sven@frisurf.no (jon-sven@frisurf.no) Date: Thu, 26 Jul 2001 01:38:50 +0200 Subject: Python 2.1.1 for DJGPP alpha Message-ID: This is a _VERY_ aplha release of Python 2.1.1 compiled with the DJGPP tools to provide binaries for 32-bit DOS systems. This is NOT to be considered a production quality release, and should only be used for testing. There are two packages available: - Python-2.1.1-djgppbin-alpha1.zip This is the compiled interpreter, libpython21.a and the module library. Simply unzip and adjust %PYTHONPATH% to install. - Python-2.1.1-djgppsrc-alpha1.zip These are the files needed to compile the original distribution. Unpack it on top of the existing source, and then $ make Do not ./configure, the archives comes with it's own config.h and Makefile. Building might require a sh-compatible shell, bash is available from ftp.simtel.net/pub/gnu/djgpp Go to http://jsven.hobbiton.org/djgpp/ to get the files Issues with this release: - os.name is currently 'posix'. This seems to work fairly well - It is statically linked, this means that all the C modules are builtin - There is no thread support - Quite a number of the tests in the testsuite are skipped because I didn't have the necessary libraries to build them available, a much higher level of completeness should be achievable. - I'm sure there are more, I'm tired. These are the testsuite results: 92 tests OK. 8 tests failed: test___all__ test_longexp test_popen2 test_socket test_sundry test_unicode test_zipfile test_zlib 35 tests skipped: test_al test_asynchat test_audioop test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gc test_gdbm test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_minidom test_mmap test_nis test_openpty test_poll test_pty test_pwd test_pyexpat test_sax test_socketserver test_sunaudiodev test_thread test_threadedtempfile test_timing test_winreg test_winsound In addition to this, test_re, test_sre, test_select and test_signal had to be skipped manually because they crashed *violently*, this should be investigated in the future. I'll be grateful for any feedback. Jon Svendsen jsvendsen@bergen.frisurf.no From ak@silmarill.org Sun Jul 22 19:27:36 2001 From: ak@silmarill.org (AK) Date: Sun, 22 Jul 2001 14:27:36 -0400 (EDT) Subject: [Application] SliceTime v0.6a Message-ID: SliceTime v0.6a --------------- Time management Keeps track of how much time you spend on multiple projects. Reports total time spent, time spend during last day, week, month and session. URL: http://silmarill.org/slicetime/ Download: http://silmarill.org/slicetime/slicetime.py License: GPL Platform: linux Categories: Applications AK (ak@silmarill.org) http://silmarill.org -- SliceTime v0.6a -- Time management From ak@silmarill.org Sun Jul 22 19:30:36 2001 From: ak@silmarill.org (AK) Date: Sun, 22 Jul 2001 14:30:36 -0400 (EDT) Subject: [Application] PyBook v0.6 Message-ID: PyBook v0.6 ----------- Console project gutenberg reader Allows searching by title/author, fetches the book, auto-bookmarks so that when you come back, it opens on the same line where you left off. URL: http://silmarill.org/pybook/ Download: http://silmarill.org/pybook/pybook.tar.gz License: GPL Platform: linux Requires: vim (or any other viewer) Categories: Applications AK (ak@silmarill.org) http://silmarill.org -- PyBook v0.6 -- Console project gutenberg reader From ngps@post1.com Thu Jul 26 16:39:50 2001 From: ngps@post1.com (Ng Pheng Siong) Date: Thu, 26 Jul 2001 23:39:50 +0800 Subject: [ANNOUNCE] M2Crypto 0.06 Message-ID: Hi, I'm pleased to announce that M2Crypto 0.06 has been released. - M2Crypto now works with (and requires) SWIG 1.3.6. - ZServerSSL has been updated to work with Zope 2.4.0. - Beginnings of unit tests for M2Crypto.SSL. (Uses fork/exec, so presently Unix only.) Going forward, I'm aiming for the following: - SSL HOWTO - Better documentation - XML-dsig implementation - SRP implementation - More unit tests of everything Get M2Crypto here: http://www.post1.com/home/ngps/m2/ As usual, feedback is appreciated. -- Ng Pheng Siong * http://www.post1.com/home/ngps Quidquid latine dictum sit, altum viditur. From rjb@catalog.net.au Wed Jul 25 12:36:19 2001 From: rjb@catalog.net.au (Ron Boles) Date: Wed, 25 Jul 2001 07:36:19 -0400 (EDT) Subject: [Application] Threaded Stock Quote Retrieval Message-ID: Threaded Stock Quote Retrieval ------------------------------ Threaded application to download stock quotes from yahoo Apologies...being a python newbee, my code is naive. (we all have to start somewhere!) -name: getQuoteThread.py -Structure: threaded python application -GUI: wxPython -Input: ascii file. Line Format = "ticker,name" -Output: ascii file of quotes I would welcome any comments. Be as rude as you like! URL: ftp://catalog.net.au/python/getQuoteThread.py Download: ftp://catalog.net.au/python/getQuoteThread.py License: Open Source Gui: wxPython Categories: Net Applications Ron Boles (rjb@catalog.net.au) -- Threaded Stock Quote Retrieval -- Threaded application to download stock quotes from yahoo From guido@zope.com Fri Jul 27 20:48:51 2001 From: guido@zope.com (Guido van Rossum) Date: Fri, 27 Jul 2001 15:48:51 -0400 Subject: Changing the Division Operator -- PEP 238, rev 1.12 Message-ID: Here's a new revision of PEP 238. I've incorporated clarifications of issues that were brought up during the discussion of rev 1.10 -- from typos via rewording of ambiguous phrasing to the addition of new open issues. I've decided not to go for the "quotient and ratio" terminology -- my rationale is in the PEP. IF YOU WANT ME TO SEE YOUR COMMENTS, FOLLOW UP TO THE COPY OF THIS ARTICLE IN COMP.LANG.PYTHON. I cannot follow all of c.l.py, but I will follow this one thread. Please don't fragment the thread -- I won't see other threads, guaranteed. --Guido van Rossum (home page: http://www.python.org/~guido/) PEP: 238 Title: Changing the Division Operator Version: $Revision: 1.12 $ Author: pep@zadka.site.co.il (Moshe Zadka), guido@python.org (Guido van Rossum) Status: Draft Type: Standards Track Created: 11-Mar-2001 Python-Version: 2.2 Post-History: 16-Mar-2001, 26-Jul-2001, 27-Jul-2001 Abstract The current division (/) operator has an ambiguous meaning for numerical arguments: it returns the floor of the mathematical result of division if the arguments are ints or longs, but it returns a reasonable approximation of the division result if the arguments are floats or complex. This makes expressions expecting float or complex results error-prone when integers are not expected but possible as inputs. We propose to fix this by introducing different operators for different operations: x/y to return a reasonable approximation of the mathematical result of the division ("true division"), x//y to return the floor ("floor division"). We call the current, mixed meaning of x/y "classic division". Because of severe backwards compatibility issues, not to mention a major flamewar on c.l.py, we propose the following transitional measures (starting with Python 2.2): - Classic division will remain the default in the Python 2.x series; true division will be standard in Python 3.0. - The // operator will be available to request floor division unambiguously. - The future division statement, spelled "from __future__ import division", will change the / operator to mean true division throughout the module. - A command line option will enable run-time warnings for classic division applied to int or long arguments; another command line option will make true division the default. - The standard library will use the future division statement and the // operator when appropriate, so as to completely avoid classic division. Motivation The classic division operator makes it hard to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs. For all other operators, one can write down a formula such as x*y**2 + z, and the calculated result will be close to the mathematical result (within the limits of numerical accuracy, of course) for any numerical input type (int, long, float, or complex). But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division. The problem is unique to dynamically typed languages: in a statically typed language like C, the inputs, typically function arguments, would be declared as double or float, and when a call passes an integer argument, it is converted to double or float at the time of the call. Python doesn't have argument type declarations, so integer arguments can easily find their way into an expression. The problem is particularly pernicious since ints are perfect substitutes for floats in all other circumstances: math.sqrt(2) returns the same value as math.sqrt(2.0), 3.14*100 and 3.14*100.0 return the same value, and so on. Thus, the author of a numerical routine may only use floating point numbers to test his code, and believe that it works correctly, and a user may accidentally pass in an integer input value and get incorrect results. Another way to look at this is that classic division makes it difficult to write polymorphic functions that work well with either float or int arguments; all other operators already do the right thing. No algorithm that works for both ints and floats has a need for truncating division in one case and true division in the other. The correct work-around is subtle: casting an argument to float() is wrong if it could be a complex number; adding 0.0 to an argument doesn't preserve the sign of the argument if it was minus zero. The only solution without either downside is multiplying an argument (typically the first) by 1.0. This leaves the value and sign unchanged for float and complex, and turns int and long into a float with the corresponding value. It is the opinion of the authors that this is a real design bug in Python, and that it should be fixed sooner rather than later. Assuming Python usage will continue to grow, the cost of leaving this bug in the language will eventually outweigh the cost of fixing old code -- there is an upper bound to the amount of code to be fixed, but the amount of code that might be affected by the bug in the future is unbounded. Another reason for this change is the desire to ultimately unify Python's numeric model. This is the subject of PEP 228[0] (which is currently incomplete). A unified numeric model removes most of the user's need to be aware of different numerical types. This is good for beginners, but also takes away concerns about different numeric behavior for advanced programmers. (Of course, it won't remove concerns about numerical stability and accuracy.) In a unified numeric model, the different types (int, long, float, complex, and possibly others, such as a new rational type) serve mostly as storage optimizations, and to some extent to indicate orthogonal properties such as inexactness or complexity. In a unified model, the integer 1 should be indistinguishable from the floating point number 1.0 (except for its inexactness), and both should behave the same in all numeric contexts. Clearly, in a unified numeric model, if a==b and c==d, a/c should equal b/d (taking some liberties due to rounding for inexact numbers), and since everybody agrees that 1.0/2.0 equals 0.5, 1/2 should also equal 0.5. Likewise, since 1//2 equals zero, 1.0//2.0 should also equal zero. Variations Aesthetically, x//y doesn't please everyone, and hence several variations have been proposed: x div y, or div(x, y), sometimes in combination with x mod y or mod(x, y) as an alternative spelling for x%y. We consider these solutions inferior, on the following grounds. - Using x div y would introduce a new keyword. Since div is a popular identifier, this would break a fair amount of existing code, unless the new keyword was only recognized under a future division statement. Since it is expected that the majority of code that needs to be converted is dividing integers, this would greatly increase the need for the future division statement. Even with a future statement, the general sentiment against adding new keywords unless absolutely necessary argues against this. - Using div(x, y) makes the conversion of old code much harder. Replacing x/y with x//y or x div y can be done with a simple query replace; in most cases the programmer can easily verify that a particular module only works with integers so all occurrences of x/y can be replaced. (The query replace is still needed to weed out slashes occurring in comments or string literals.) Replacing x/y with div(x, y) would require a much more intelligent tool, since the extent of the expressions to the left and right of the / must be analyzed before the placement of the "div(" and ")" part can be decided. Alternatives In order to reduce the amount of old code that needs to be converted, several alternative proposals have been put forth. Here is a brief discussion of each proposal (or category of proposals). If you know of an alternative that was discussed on c.l.py that isn't mentioned here, please mail the second author. - Let / keep its classic semantics; introduce // for true division. This still leaves a broken operator in the language, and invites to use the broken behavior. It also shuts off the road to a unified numeric model a la PEP 228[0]. - Let int division return a special "portmanteau" type that behaves as an integer in integer context, but like a float in a float context. The problem with this is that after a few operations, the int and the float value could be miles apart, it's unclear which value should be used in comparisons, and of course many contexts (like conversion to string) don't have a clear integer or float context. - Use a directive to use specific division semantics in a module, rather than a future statement. This retains classic division as a permanent wart in the language, requiring future generations of Python programmers to be aware of the problem and the remedies. - Use "from __past__ import division" to use classic division semantics in a module. This also retains the classic division as a permanent wart, or at least for a long time (eventually the past division statement could raise an ImportError). - Use a directive (or some other way) to specify the Python version for which a specific piece of code was developed. This requires future Python interpreters to be able to emulate *exactly* several previous versions of Python, and moreover to do so for multiple versions within the same interpreter. This is way too much work. A much simpler solution is to keep multiple interpreters installed. API Changes During the transitional phase, we have to support *three* division operators within the same program: classic division (for / in modules without a future division statement), true division (for / in modules with a future division statement), and floor division (for //). Each operator comes in two flavors: regular, and as an augmented assignment operator (/= or //=). The names associated with these variations are: - Overloaded operator methods: __div__(), __floordiv__(), __truediv__(); __idiv__(), __ifloordiv__(), __itruediv__(). - Abstract API C functions: PyNumber_Divide(), PyNumber_FloorDivide(), PyNumber_TrueDivide(); PyNumber_InPlaceDivide(), PyNumber_InPlaceFloorDivide(), PyNumber_InPlaceTrueDivide(). - Byte code opcodes: BINARY_DIVIDE, BINARY_FLOOR_DIVIDE, BINARY_TRUE_DIVIDE; INPLACE_DIVIDE, INPLACE_FLOOR_DIVIDE, INPLACE_TRUE_DIVIDE. - PyNumberMethod slots: nb_divide, nb_floor_divide, nb_true_divide, nb_inplace_divide, nb_inplace_floor_divide, nb_inplace_true_divide. The added PyNumberMethod slots require an additional flag in tp_flags; this flag will be named Py_TPFLAGS_HAVE_NEWDIVIDE and will be included in Py_TPFLAGS_DEFAULT. The true and floor division APIs will look for the corresponding slots and call that; when that slot is NULL, they will raise an exception. There is no fallback to the classic divide slot. In Python 3.0, the classic division semantics will be removed; the classic division APIs will become synonymous with true division. Command Line Option The -D command line option takes a string argument that can take three values: "old", "warn", or "new". The default is "old" in Python 2.2 but will change to "warn" in later 2.x versions. The "old" value means the classic division operator acts as described. The "warn" value means the classic division operator issues a warning (a DeprecationWarning using the standard warning framework) when applied to ints or longs. The "new" value changes the default globally so that the / operator is always interpreted as true division. The "new" option is only intended for use in certain educational environments, where true division is required, but asking the students to include the future division statement in all their code would be a problem. This option will not be supported in Python 3.0; Python 3.0 will always interpret / as true division. (Other names have been proposed, like -Dclassic, -Dclassic-warn, -Dtrue, or -Dold_division etc.; these seem more verbose to me without much advantage. After all the term classic division is not used in the language at all (only in the PEP), and the term true division is rarely used in the language -- only in __truediv__.) Semantics of Floor Division Floor division will be implemented in all the Python numeric types, and will have the semantics of a // b == floor(a/b) except that the result type will be the common type into which a and b are coerced before the operation. Specifically, if a and b are of the same type, a//b will be of that type too. If the inputs are of different types, they are first coerced to a common type using the same rules used for all other arithmetic operators. In particular, if a and b are both ints or longs, the result has the same type and value as for classic division on these types (including the case of mixed input types; int//long and long//int will both return a long). For floating point inputs, the result is a float. For example: 3.5//2.0 == 1.0 For complex numbers, // raises an exception, since float() of a complex number is not allowed. For user-defined classes and extension types, all semantics are up to the implementation of the class or type. Semantics of True Division True division for ints and longs will convert the arguments to float and then apply a float division. That is, even 2/1 will return a float (2.0), not an int. For floats and complex, it will be the same as classic division. Note that for long arguments, true division may lose information; this is in the nature of true division (as long as rationals are not in the language). Algorithms that consciously use longs should consider using //. If and when a rational type is added to Python (see PEP 239[2]), true division for ints and longs should probably return a rational. This avoids the problem with true division of longs losing information. But until then, for consistency, float is the only choice for true division. The Future Division Statement If "from __future__ import division" is present in a module, or if -Dnew is used, the / and /= operators are translated to true division opcodes; otherwise they are translated to classic division (until Python 3.0 comes along, where they are always translated to true division). The future division statement has no effect on the recognition or translation of // and //=. See PEP 236[4] for the general rules for future statements. (It has been proposed to use a longer phrase, like "true_division" or "modern_division". These don't seem to add much information.) Open Issues - It has been proposed to call // the quotient operator, and the / operator the ratio operator. I'm not sure about this -- for some people quotient is just a synonym for division, and ratio suggests rational numbers, which is wrong. I prefer the terminology to be slightly awkward if that avoids unambiguity. Also, for some folks "quotient" suggests truncation towards zero, not towards infinity as "floor division" says explicitly. - It has been argued that a command line option to change the default is evil. It can certainly be dangerous in the wrong hands: for example, it would be impossible to combine a 3rd party library package that requires -Dnew with another one that requires -Dold. But I believe that the VPython folks need a way to enable true division by default, and other educators might need the same. These usually have enough control over the library packages available in their environment. - For very large long integers, the definition of true division as returning a float causes problems, since the range of Python longs is much larger than that of Python floats. This problem will disappear if and when rational numbers are supported. In the interim, maybe the long-to-float conversion could be made to raise OverflowError if the long is out of range. FAQ Q. Why isn't true division called float division? A. Because I want to keep the door open to *possibly* introducing rationals and making 1/2 return a rational rather than a float. See PEP 239[2]. Q. Why is there a need for __truediv__ and __itruediv__? A. We don't want to make user-defined classes second-class citizens. Certainly not with the type/class unification going on. Q. How do I write code that works under the classic rules as well as under the new rules without using // or a future division statement? A. Use x*1.0/y for true division, divmod(x, y)[0] for int division. Especially the latter is best hidden inside a function. You may also write float(x)/y for true division if you are sure that you don't expect complex numbers. If you know your integers are never negative, you can use int(x/y) -- while the documentation of int() says that int() can round or truncate depending on the C implementation, we know of no C implementation that doesn't truncate, and we're going to change the spec for int() to promise truncation. Note that for negative ints, classic division (and floor division) round towards negative infinity, while int() rounds towards zero. Q. How do I specify the division semantics for input(), compile(), execfile(), eval() and exec? A. They inherit the choice from the invoking module. PEP 236[4] lists this as a partially resolved problem. Q. What about code compiled by the codeop module? A. Alas, this will always use the default semantics (set by the -D command line option). This is a general problem with the future statement; PEP 236[4] lists it as an unresolved problem. You could have your own clone of codeop.py that includes a future division statement, but that's not a general solution. Q. Will there be conversion tools or aids? A. Certainly, but these are outside the scope of the PEP. Q. Why is my question not answered here? A. Because we weren't aware of it. If it's been discussed on c.l.py and you believe the answer is of general interest, please notify the second author. (We don't have the time or inclination to answer every question sent in private email, hence the requirement that it be discussed on c.l.py first.) Implementation A very early implementation (not yet following the above spec, but supporting // and the future division statement) is available from the SourceForge patch manager[5]. References [0] PEP 228, Reworking Python's Numeric Model http://www.python.org/peps/pep-0228.html [1] PEP 237, Unifying Long Integers and Integers, Zadka, http://www.python.org/peps/pep-0237.html [2] PEP 239, Adding a Rational Type to Python, Zadka, http://www.python.org/peps/pep-0239.html [3] PEP 240, Adding a Rational Literal to Python, Zadka, http://www.python.org/peps/pep-0240.html [4] PEP 236, Back to the __future__, Peters, http://www.python.org/peps/pep-0236.html [5] Patch 443474, from __future__ import division http://sourceforge.net/tracker/index.php?func=detail&aid=443474&group_id=5470&atid=305470 Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: From bckfnn@worldonline.dk Sun Jul 29 22:22:44 2001 From: bckfnn@worldonline.dk (Finn Bock) Date: Sun, 29 Jul 2001 21:22:44 GMT Subject: ANN: Third alpha release of Jython-2.1 Message-ID: I am happy to announce the third 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 on version 2.1a3 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.1 and among the new feature are: - A settable console encoding will allow windows users to enter national characters at the command prompt. - The names of zip- and jarfiles can be added to sys.path. A complete list of changes and differences are available here: http://www.jython.org/NEWS.html A list of fixed bugs can be found here: http://sourceforge.net/tracker/?group_id=12867&atid=112867 Change the Status input box to "Closed" and the Group input box to "Fixed in 2.1a3" and press the "Browse" button. Bugs can be reported to the bug manager on SourceForge: http://sourceforge.net/bugs/?group_id=12867 Cheers, the jython-developers From richard@optushome.com.au Sun Jul 29 11:33:11 2001 From: richard@optushome.com.au (Richard Jones) Date: Sun, 29 Jul 2001 06:33:11 -0400 Subject: Roundup issue tracker version 0.2.2 Message-ID: Roundup 0.2.2 - an issue tracking system Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this release. The contact for this project is richard@sourceforge.net. Roundup manages a number of issues (with properties such as "description", "priority", and so on) and provides the ability to (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.0+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates and three database back-ends. Back-ends for relational databases are being developed. Source is available at the website: http://sourceforge.net/projects/roundup/ Changes: See the release notes on the website or the CHANGES.txt distributed with the source. This is the first "public" release. From richard@bizarsoftware.com.au Mon Jul 30 05:19:15 2001 From: richard@bizarsoftware.com.au (Richard Jones) Date: Mon, 30 Jul 2001 14:19:15 +1000 Subject: Roundup issue tracker version 0.2.3 Message-ID: Roundup 0.2.3 - an issue tracking system Changes: See the release notes on the website or the CHANGES.txt distributed with the source. This is a feature-add and bug-fix release. Users who downloaded 0.2.2 should read CHANGES.txt and upgrade immediately. Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard@sourceforge.net. Roundup manages a number of issues (with flexible properties such as "description", "priority", and so on) and provides the ability to (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.0+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates and three database back-ends. Back-ends for relational databases are being developed. Source is available at the website: http://sourceforge.net/projects/roundup/ -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) From guido@zope.com Mon Jul 30 21:22:03 2001 From: guido@zope.com (Guido van Rossum) Date: Mon, 30 Jul 2001 16:22:03 -0400 Subject: www.python.org is down Message-ID: We have a broken hard drive on the machine that is www.python.org. CNRI claims there is no spare drive. It may be a while before we resolve this. In the mean time, here's a mirror: http://mirrors.ccs.neu.edu/Python/www.python.org/ Here's a list of mirrors: http://mirrors.ccs.neu.edu/Python/www.python.org/Mirrors.html --Guido van Rossum (home page: http://www.python.org/~guido/)