Mailman 3 August 2003 - Python-announce-list

ANN: eGenix.com mxODBC Python Database Interface Version 2.0.6
by M.-A. Lemburg Aug. 12, 2003

Aug. 12, 2003

________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.3 Version 2.0.6 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx Commercial Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, 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. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.6 version includes patches needed to compile the package for Python 2.3. Binaries are available for Python 1.5.2, 2.0, 2.1, 2.2 and 2.3 for Windows and Linux. ________________________________________________________________________ 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.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages IMPORTANT: In order to use the eGenix.com mx Commercial package you will first need to install the eGenix.com mx Base package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details or go directly to our secure online shop: http://shop.egenix.com/ ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 12 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________

1 0

ANN: eGenix.com mx Experimental Package 0.8.0
by M.-A. Lemburg Aug. 12, 2003

Aug. 12, 2003

________________________________________________________________________ ANNOUNCING: eGenix.com mx Experimental Extension Package for Python 1.5.2 - 2.3 Version 0.8.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 object-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 new version includes patches needed to compile the packages under Python 2.3. 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 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 longs 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 mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ 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 comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 12 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________

1 0

ANN: eGenix.com mx Base Extension Package 2.0.5
by M.-A. Lemburg Aug. 12, 2003

Aug. 12, 2003

________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python 1.5.2 - 2.3 Version 2.0.5 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 object-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. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform 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 new version includes patches needed to compile the packages under Python 2.3. 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.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The Base package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. Full source code is included. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Aug 12 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________

1 0

ANN: pychains-0.1.0
by Rich Harkins Aug. 11, 2003

Aug. 11, 2003

pychains is a C-based python module providing a couple of useful Python types that delegate certain requests (__getitem__ and __getattr__) to other objects. Using pychains one can create dictionaries that are aggregates of other dictionaries, objects whose attributes come from numerous other objects, etc. Documentation, as it stands, is available on the home page as is the download link: http://pychains.sourceforge.net STANDARD DISCLAIMER: This code is *very* alpha. I'm using it in some of my projects and it hasn't crashed in a while so I'm allowing it into the source-compiling public for further testing, etc. I'm suspicious it may be leaking memory and I cannot guarantee it won't do something horrible. PLEASE don't use it where it doesn't belong (mission critical stuff). Regards, Rich -- Rich Harkins <rich(a)worldsinfinite.com>

1 0

Retic EAI Server 0.1 released
by Alexander DEJANOVSKI Aug. 11, 2003

Aug. 11, 2003

Retic is a free EAI Server written in Python. It permits to build adaptors (data flows) with three types of components : sources, pipes and sinks. It was widely inspired by OpenAdaptor. The 0.1 release has the following components available : Sources : File, FTP, HTTP, SQL Pipes : toXML (flat to XML) , XSLT Sinks : File, FTP, SQL, SMTP Retic can be downloaded from its sourceforge home page : https://sourceforge.net/projects/retic/ More info and documentation can be found on : http://retic.sourceforge.net

1 0

ANN: dnspython 1.1.0
by Bob Halley Aug. 11, 2003

Aug. 11, 2003

dnspython 1.1.0 has been released. Here's the README: dnspython INTRODUCTION dnspython is a DNS toolkit for Python. It supports almost all record types. It can be used for queries, zone transfers, and dynamic updates. It supports TSIG authenticated messages and EDNS0. dnspython provides both high and low level access to DNS. The high level classes perform queries for data of a given name, type, and class, and return an answer set. The low level classes allow direct manipulation of DNS zones, messages, names, and records. To see a few of the ways dnspython can be used, look in the examples/ directory. dnspython originated at Nominum where it was developed to facilitate the testing of DNS software. Nominum has generously allowed it to be open sourced under a BSD-style license, and helps support its future development by continuing to employ the author :). ABOUT THIS RELEASE This is dnspython 1.1.0. New since 1.0.0: Message sections are now lists of RRsets, not lists of nodes. Nodes no longer have names; owner names are associated with nodes in the Zone object's nodes dictionary. Many tests have been added to the test suite; dnspython 1.0.0 has 47 tests, 1.1.0 has 275. The improved testing uncovered a number of bugs, all of which have been fixed. The NameDict class provides a dictionary whose keys are DNS names. In addition to behaving like a normal Python dictionary, it also provides the get_deepest_match() method. If, for example, you had a dictionary containing the keys foo.com and com, then get_deepest_match() of the name a.b.foo.com would match the foo.com key. A new Renderer class for those applications which want finer control over the DNS wire format message generation process. Support for a "TooBig" exception if the size of wire format output exceeds a specified limit. Zones now have find_rrset() and find_rdataset() convenience methods. They let you retrieve rdata with the specified name and type in one call, e.g.: rrset = zone.find_rrset('foo', 'mx') Other new zone convenience methods include: find_node(), delete_node(), delete_rdataset(), replace_rdataset(), iterate_rdatasets(), and iterate_rdatas(). get_ variants of find_ methods are provided; the difference is that get_ methods return None if the desired object doesn't exist, whereas the find_ methods raise an exception. Zones now have a to_file() method. The message and zone from_file() methods allow Unicode filenames on platforms (and versions of python) which support them. Universal newline support is also used if available. The Zone class now implements more of the standard mapping interface. E.g. you can say zone.keys(), zone.get('name'), zone.iteritems(), etc. __iter__() has been changed to iterate the keys rather than values to match the standard mapping interface's behavior. Rdatasets support more set operations Zone and Node factories may be specified, allowing applications to subclass Zone or Node and yet still use the algorithms which build zones from master files or AXFR data. dns.ipv6.inet_ntoa() now minimizes the text representation of IPv6 addresses in the usual way, e.g. "0000:0000:0000:0000:0000:0000:0000:0001" is minimized to "::1". dns.query functions now take an optional address family parameter. This release fixes all known bugs. See the ChangeLog file for more detailed information on changes since the prior release. REQUIREMENTS Python 2.2 or later. INSTALLATION To build and install dnspython, type python setup.py install HOME PAGE For the latest in releases, documentation, and information, visit the dnspython home page at http://www.dnspython.org/ DOCUMENTATION Documentation is sparse at the moment. Use pydoc, or read the HTML documentation at the dnspython home page, or download the HTML documentation. BUG REPORTS Bug reports may be sent to bugs(a)dnspython.org MAILING LISTS A number of mailing lists are available. Visit the dnspython home page to subscribe or unsubscribe.

1 0

python-dev Summary for 2003-07-01 through 2003-07-31
by Brett C. Aug. 10, 2003

Aug. 10, 2003

python-dev Summary for 2003-07-01 through 2003-07-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from July 1, 2003 through July 31, 2003. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to python-list(a)python.org or `comp.lang.python`_ with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the twenty-first/twenty-second summary written by Brett Cannon (who is still learning how to count; gave the wrong summary count last month). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; its simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the original text file. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on something mentioned here. Python PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-06-01_2003-06-30.html ===================== Summary Announcements ===================== It's experimentation time again! In preparation for having to cut down on the breadth of the summary thanks to my return to school I am starting this summary off as the inaugural release of the new format. Pretty much everything is going to change somewhat. First, though, I think I should explain my new viewpoint towards the summaries that I am taking. In order to continue to provide a certain level of quality and coverage while retaining my personal sanity and to not feel like the Summaries are a job instead of something I do for fun and to help others, I am going to start viewing the Summaries more from a journalistic perspective than a historical one. Before I felt more like a historian that was summarizing *everything* that happened on python-dev. Now, though, I am be more like a journalist, covering only the pertinent ideas. This also allows me to inject more of my personality into my writing. But what ramifications does this new perspective cause? Well, it will dictate what I do and do not summarize. I plan on several types of discussions to be covered in the Summaries. One is new features of the language. This is so people can know about them ASAP and thus comment on them. Since practically any feature mentioned here is experimental there is a chance to remove it if a community movement mounts. I will also cover any major thinking on the future of Python. I have always wished there was an easy way to see what pie-in-the-sky ideas python-dev was thinking of in the back of our collective mind; the summaries might as well fill this desire. And of course any random discussion that is large, important, and/or complex will continue to be covered. In terms of formatting and layout, that will also change along with the new viewpoint. I am planning to follow something more along the lines of the Perl's `This Week... <http://dev.perl.org/perl6/list-summaries/>`__; yes, I am taking a cue from Perl but AM Kuchling and Michael Hudson originally used this format as well. This means titles of summary sections will more reflect the topic being summarized rather than the specific thread(s). I will continue to list all of the threads that contributed to the summary, though, for reference purposes. I feel this will be beneficial since I know I have personally looked back into the Summary archives and had a hard time finding something specific since the subject of a thread does not always match the topic of discussion; if I can't find something and I know about what month it happened I can only imagine what everyone else has had to go through to find something! I am removing the Quickies section from the Summaries. This section was nice to have, but it just ate away at my time. This also goes along with the new viewpoint. I am sure not everyone will be happy with this change, that's fine. But if someone out there *truly* hates the direction I am going then they can step forward and take the reigns from me. But as I have stated before, the fine print on me giving up this post is that the person who takes over must be as thorough as I *used* to be; I can do the summaries in a half-assed fashion as well as anyone else. Enough of that topic. One thing I would like to mention is that the `Python Software Foundation`_ can now accept donations through PayPal. Specifics can be found at http://www.python.org/psf/donations.html . It would be great if people could donate since the PSF is more than just a non-profit to hold the Python intellectual property. One of the goals of the group is to get enough money to do something like the Perl Foundation does and sponsor someone to hack on Python for a living for a set amount of time. Right now we are a ways off from having that kind of revenue, but there is no reason why we can't. Heck, if we can just get enough to sponsor one person to do full-time Python hacking for a week it would be beneficial. Or better yet, the PSF could sponsor one of their own members to write a summary of the python-dev mailing list for the betterment of the community. =) .. _PSF: .. _Python Software Foundation: http://www.python.org/psf/ .. _PayPal: http://www.paypal.com/ ========= Summaries ========= -------------------------- Python 2.3 final released! -------------------------- In case for some odd reason you didn't know, Python 2.3 final has gone out the door. The team managed to meet the goal of getting it out by the end of the month so that Apple_ can use a final release instead of a release candidate in OS X 10.3 (a.k.a. Panther). The goal of this release was to continue to improve Python without adding any new keywords. This was met while speeding things up, fixing bugs, adding to the standard library, and adding some new built-ins. To find out what is new or has changed look at the changelog at http://www.python.org/2.3/highlights.html or `What's New in Python 2.3`_. As with all software, there are bound to be bugs. What bugs that are known are listed at http://www.python.org/2.3/bugs.html . If you find bugs not listed there, please report them on the SourceForge bug tracker at http://sourceforge.net/tracker/?group_id=5470&atid=105470 . Running the regression test suite (details on how to do this is covered in the documentation for the 'test' package as found at http://www.python.org/doc/current/lib/module-test.html) is always appreciated. Contributing threads: - `Problem with 2.3b2 tarfile?`__ - `MacPython 2.3b2 binary installer for MacOSX`__ - `Running tests on freebsd5`__ - `Python 2.3 release schedule update`__ - `Vacation and possibly a new bug`__ - `Doc/ tree closes at noon, US/Eastern`__ - `I've tagged the tree`__ - `cygwin errors`__ - `test_strptime; test_logging; test_time failure`__ - `2.3rc1 delayed`__ - `Python 2.3 release candidate 1`__ - `post-release festivities`__ - `New branch for r23c2 work`__ - `Serious CallTip Bug in IDLE`__ - `MacPython-OS9 test failures`__ - `Doc/ tree on trunk closed`__ - `Cutting the 2.3c2 tonight 8pm EDT`__ - `Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827`__ - `RELEASED Python 2.3c2`__ - `2.3rc2 IDLE problems on a Win2000sp3 box`__ - `Draft: 2.3 download page`__ - `Last priority >= 7 bug for Python 2.3`__ - `CVS Freeze`__ - `RELEASED Python 2.3 (final)`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036669.html __ http://mail.python.org/pipermail/python-dev/2003-July/036732.html __ http://mail.python.org/pipermail/python-dev/2003-July/036762.html __ http://mail.python.org/pipermail/python-dev/2003-July/036783.html __ http://mail.python.org/pipermail/python-dev/2003-July/036845.html __ http://mail.python.org/pipermail/python-dev/2003-July/036892.html __ http://mail.python.org/pipermail/python-dev/2003-July/036899.html __ http://mail.python.org/pipermail/python-dev/2003-July/036900.html __ http://mail.python.org/pipermail/python-dev/2003-July/037117.html __ http://mail.python.org/pipermail/python-dev/2003-July/036921.html __ http://mail.python.org/pipermail/python-dev/2003-July/036940.html __ http://mail.python.org/pipermail/python-dev/2003-July/036941.html __ http://mail.python.org/pipermail/python-dev/2003-July/037024.html __ http://mail.python.org/pipermail/python-dev/2003-July/037134.html __ http://mail.python.org/pipermail/python-dev/2003-July/037144.html __ http://mail.python.org/pipermail/python-dev/2003-July/037193.html __ http://mail.python.org/pipermail/python-dev/2003-July/037200.html __ http://mail.python.org/pipermail/python-dev/2003-July/037207.html __ http://mail.python.org/pipermail/python-dev/2003-July/037208.html __ http://mail.python.org/pipermail/python-dev/2003-July/037237.html __ http://mail.python.org/pipermail/python-dev/2003-July/037284.html __ http://mail.python.org/pipermail/python-dev/2003-July/037311.html __ http://mail.python.org/pipermail/python-dev/2003-July/037315.html __ http://mail.python.org/pipermail/python-dev/2003-July/037319.html .. _Apple: http://www.apple.com/ .. _What's New in Python 2.3: http://www.python.org/doc/2.3/whatsnew/ ------------------------------------------- String Exceptions Going Extinct, Eventually ------------------------------------------- It has been brought up several times before, but things are now moving along to eventually deprecate string exceptions (e.g., ``raise "this string exception"``). they have now been removed from the tutorial to prevent people new to the language from picking up habits that will eventually be impossible to perform. As for when the impending deprecation will occur only Guido knows. The chances of it coming before Python 3, though, is most likely small. Contributing threads: - `String exceptions in the Tutorial`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036665.html -------------------------------------------------------- Someday, My CVS updates Will Succeed on the First Try... -------------------------------------------------------- We all know that SourceForge_ does not have the snappiest or most reliable CVS_ servers in the world; Python 2.3 final's release was targeted a few days earlier than needed for Apple_ in case SF's CVS went down. Solutions to how to deal with this problem have come up. One specific problem that people are trying to solve is the poor anonymous pserver access. SF has their CVS servers set up so that authorized CVS commands take priority over anonymous ones and thus when there is heavy traffic anonymous CVS basically shuts down. Martin v. Löwis put up a link to a nightly tarball at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python.tgz of the CVS HEAD. perl.org has provided a nightly tarball as well at http://cvs.perl.org/snapshots/python/ for quite some time now. The suggestion of having a read-only version of the CVS tree on python.org was came up, but how to properly do it and who would set it up was not settled. And of course there is always the option of moving CVS off of SF entirely. There is one offer on the table with the caveat that we need to know what kind of bandwidth demands we would have. Another offer sprung up this month from Michal Wallace to host our CVS at http://www.versionhost.com/ with the hitch that it requires an external Python script for secure connections (as specified at http://www.sabren.net/code/cvssh/ ). Contributing threads: - `alternate pserver access for python CVS?`__ - `[fwd] SourceForge status`__ - `Volunteering to help with pserver cvs on python.org`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036699.html __ http://mail.python.org/pipermail/python-dev/2003-July/036708.html __ http://mail.python.org/pipermail/python-dev/2003-July/036860.html .. _SourceForge: http://www.sf.net/ .. _CVS: http://www.cvshome.org/ --------------------- Which License to Use? --------------------- Domenico Andreoli wanted to donate `python-crack`_ to the PSF_ and wondered what steps would be necessary to do so. He was first told that the module would not be included in Python since it is too specific. Secondly, it was suggested he not choose the PSF license. Instead, he was told that he should use the BSD or MIT license (both of which can be found at http://www.opensource.org/licenses/index.php); clean, simple licenses that are not viral like the GPL but are GPL-compatible. This is so that it can be included in any software that uses Python. Contributing threads: - `donating python-crack module`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036712.html .. _python-crack: http://savannah.nongnu.org/projects/python-crack ---------------- Not Quite ANSI C ---------------- Every so often someone runs Python against a C code checker and notices failures that get reported to us. Often, though, we have to tell the person that we already know of the failures and that there is nothing to worry about. This time it was failures under Purify. We have also received reports of failures under Valgrind_ which are spurious. The language isn't even fully ANSI C compliant, but as Tim Peters said, "it's not possible to write a useful and portable memory allocator in 100% standard ANSI C" among other reasons why strict ANSI C conformity is broken. The only major violations in the code are casting a pointer to a unsigned integer type and assuming "that whatever memory protection gimmicks an OS implements are at page granularity" which is a minor sin at best. There is also some cases of accessing memory without proper casting. Contributing threads: - `Invalid memory read in PyObject_Free`__ - `strict aliasing and Python`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036717.html __ http://mail.python.org/pipermail/python-dev/2003-July/036898.html .. _Valgrind: http://developer.kde.org/~sewardj/ --------------------------------------- Shadowing Built-ins is Becoming a No-No --------------------------------------- Before the code was removed, Python 2.3 raised a DeprectionWarning when you overshadowed a built-in in a module from outside the module's actual code. What this means is that doing something like:: import mod mod.reload = 42 would raise the warning. Now doing ``reload = 42`` in the module itself would still be allowed. The idea was (and still is) that the compiler can know when a built-in is shadowed in a module when it compiles the module's code. But allowing someone to overwrite a built-in externally means that the compiler cannot make any assumptions that built-ins will forever reference the actual built-in code. This is unfortunate since if shadowing externally was made illegal the compiler can reference the built-in code directly and skip some steps for a nice speed-up. This is why there was code to warn against this initially. But it didn't work well enough to be left in Python 2.3 so it has been removed. But this restriction will most likely be enforced at some point so it is something to keep in mind. Contributing threads: - `Deprecation warning 'assignment shadows builtin'`__... - `DeprecationWarning: assignment shadows builtin`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036767.html __ http://mail.python.org/pipermail/python-dev/2003-July/036879.html ------------------------ Must...Start...Faster... ------------------------ While Python 2.3 sees up to a 30% speed increase over 2.2, it still starts up slower. Originally it was believed that it was because of the importation of the re module. Marc-André Lemburg applied a patch that tried to minimize its possible importation at startup but it was still slow. Jeremy Hylton pointed out that 2.2.3 imported re so that probably was not the problem. One thing that is different, though, is the automatic inclusion of warnings, codecs, and the ability to do zip imports. These three things pull more modules and all of this leads to a longer startup time. There is also the importation of distutils thanks to the site.py module, but that only occurs if you execute in a build directory. Including zip imports also got attacked for the number of failed checks for files it can incur. But it is believed this is not as bad as all of the extra imports being done now and Just van Rossum said he would try to cut down the unneeded checks in the future. Contributing threads: - `2.3 startup speed?`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036815.html --------------------- The World and Numbers --------------------- People might not be aware of it, but locale.setlocale never changes the LC_NUMERIC locale value. This is so that 'str' and 'float' can return and receive numbers in a consistent way in source code. This causes a problem, though, for people in locales that do not use a period for a decimal point. If you had your locale set to Brazilian and tried to pass the string "3,14" to 'float' it would fail even though that is a legitimate number representation for your locale. The suggestion became to have a locale-agnostic version of 'str' and 'float' in the locale module for people to use when they needed such functionality. It has now reached the stage of a rough draft PEP as found at http://mail.python.org/pipermail/python-dev/2003-July/036996.html . Contributing threads: - `LC_NUMERIC and C libraries`__ - `Be Honest about LC_NUMERIC`__ - `RE: [Spambayes] Question (or possibly a bug report)`__ __ http://mail.python.org/pipermail/python-dev/2003-July/036869.html __ http://mail.python.org/pipermail/python-dev/2003-July/036996.html __ http://mail.python.org/pipermail/python-dev/2003-July/037178.html --------------- Zippin' Nothin' --------------- The built-in 'zip' function in Python 2.3 raises TypeError when given no arguments. This causes problem when you do ``zip(*args)`` and args is empty. So for Python 2.4 'zip' with no arguments will return an empty list. Contributing threads: - `zip() in Py2.4`__ __ http://mail.python.org/pipermail/python-dev/2003-July/037332.html -------------------------------- A Syntax For Function Attributes -------------------------------- An old debate (or at least old in terms of it having popped up multiple times during the tenure of your author) has been ways of enhancing function definitions. Previously it has been over ways to make defining classmethod and its ilk in a cleaner fashion along with properties (past summaries on this can be found at http://www.python.org/dev/summary/2003-01-16_2003-01-31.html#extended-funct… and http://www.python.org/dev/summary/2003-02-01_2003-02-15.html#extended-funct… ). What made the discussion slightly different this time, though, was the focus was on function attributes specifically. One idea was to tweak Michael Hudson's bracket syntax for method annnotations to allow for function attributes; ``def foo() [bar=42]: pass``. Another suggestion was to take the dictionary-like connection even farther; ``def foo() {bar=42}: pass``. There was no clear winner in either case partially because this discussion flared up towards the end of the month. It was also pointed out that using Michael Hudson's method descriptors you could come up with a wrapping function that handled the situation:: def attrs(**kw): def _(func): for k in kw: setattr(func, k, kw[k]) return func return _ def foo() [attrs(bar=42)]: pass Perk of this is it does not lead to any special syntax just for function attributes. One drawback, though, as pointed out by Paul Moore is that this makes the method annotation idea a little to liberal and open to hackish solutions like this that will lead to abuse. This was not a huge worry, though, since almost anything can be abused and this is all already doable now, just without a nice, clean syntax. Contributing threads: - `A syntax for function attributes?`__ __ http://mail.python.org/pipermail/python-dev/2003-July/037338.html

1 0

Re: series (was: streams (was: reiter)))
by Beni Cherniavsky Aug. 10, 2003

Aug. 10, 2003

Beni Cherniavsky wrote on 2003-08-10: > Thus I'm releasing the module under yet another name: > > http://www.technion.ac.il/~cben/python/series.py > > I'd like to stop the renamings at this stage, so if you don't like it, > speak now :-). > [Sorry, hit Send too soon...] Here is the summary of what this is: This module exposes the duality between linked lists and iterators: - Simple linked lists have the drawback that their tail must be known and finite. This can be fixed by overloading head/tail access and making it lazy; the result is popular in functional programming languages [1]_. This is implemented by the `Series` and `UncomputedSeries` classes. - Iterators have the drawback that advancing them is destructive but there is no way to capture the ''remaining future'' of an iterator at some moment. This can be fixed by making an iterator explicitly point to a series and allow separate iterators to be forked from it. This is implemented by the `SeriesIter` class. Another useful thing about linked lists is that you can non-destructively cons items in front of them. This is implemented by the `Series` class (which is also used to represent the part of series that has already been computed) and is also accessible through the `SeriesIter.unyield()` method. A convenince subscripting interface is provided for series. -- Beni Cherniavsky <cben(a)tx.technion.ac.il>

1 0

series (was: streams (was: reiter)))
by Beni Cherniavsky Aug. 10, 2003

Aug. 10, 2003

I was reminded by Paul Foley that CL has an unambiguos name for the concept: "series". Well, actually what the series package in CL does is quite different from what I want but the name is very good so I'll borrow it anyway ;-). At a high enough level of abstraction, it's very related. Thus I'm releasing the module under yet another name: http://www.technion.ac.il/~cben/python/series.py I'd like to stop the renamings at this stage, so if you don't like it, speak now :-). Renaming details: - Module name: `streams` -> `series` - `Cons` -> `Series` - `Stream` -> `UncomputedSeries` (you don't have to ever type this name as `Series()` is now a factory creating an `UncomputedSeries` object when called with one argument). - `StreamIter` -> `SeriesIter` - `StreamIter.fork` -> `SeriesIter.copy` Also I squashed a bug in `__repr__` - it referenced an undefined variable. What -- Beni Cherniavsky <cben(a)tx.technion.ac.il>

1 0

Ann: pxdom, a DOM implementation
by Andrew Clover Aug. 10, 2003

Aug. 10, 2003

pxdom is a stand-alone pure-Python DOM implementation and non-validating parser, supporting Level 3 Core, XML, Load and Save specifications. pxdom was written to support the needs of PXTL, but is a general-purpose implementation suitable for any DOM-based application. It can be included as a module inside packages that must rely on a fully-working DOM regardless of what version of Python or PyXML is installed. The emphasis of pxdom is on standards compliance. It supports the W3C specifications fully, with only very minor deviations (namely: not all possible invalid Unicode characters are checked for, and it is lenient about what nodes a Document may contain, for whitespace-handling purposes in particular). pxdom passes the DOM L1/2 Core Test Suite. The emphasis of pxdom is *not* on efficiency. General speed and memory usage can be expected to be somewhere between minidom and 4DOM levels, nowhere near cDomlette. Exactly how slow pxdom is remains to be seen; currently it has only been tested with the DOM Test Suite (where it was much slower than minidom) and PXTL (where it was - inexplicably - considerably faster). YMMV. Because of the relatively small number of applications it has been tested with, and above all because the DOM Level 3 spec is still subject to change (though it is now at Last Call), pxdom 0.6 is considered beta software. pxdom is compatible with Python 1.5.2 and later (tested up to 2.3); for correct Unicode support Python 1.6 or later is required. It is available under a new-BSD-style licence from: http://www.doxdesk.com/software/py/pxdom.html -- Andrew Clover mailto:and@doxdesk.com http://www.doxdesk.com/

1 0