Python-announce-list October 2000

python-announce-list@python.org

28 participants
41 discussions

[ANNOUNCE] Ninth International Python Conference

by Paul F. Dubois

CALL FOR PAPERS, POSTERS, AND PARTICIPATION Ninth International Python Conference March 5-8, 2001 Long Beach, California Web site: http://python9.org The 9th International Python Conference (Python 9) is a forum for Python users, software developers, and researchers to present current work, discuss future plans for the language and commercial applications, and learn about interesting uses of Python. The conference will consist of a day of tutorials, two days of refereed paper and application tracks including a Zope track and a multi-technology Python Applications Track, a developers' day, a small exhibition, demonstrations, and posters. Paper submission deadline: Monday, November 6, 2000 Notification of acceptance: Monday, December 11, 2000 Final papers due: Monday, January 15, 2001 Authors are invited to submit papers for the Refereed Paper Track that: * Present new and useful applications and tools that utilize Python * Describe the use of Python in large, mission-critical or unusual applications * Address practical programming problems, and provide lessons based on experience for Python programmers Also sought are poster presentations of interesting work in progress. Full information is available on the website, http://python9.org

20 years, 6 months

Martel-0.3 - a regexp engine generating SAX events

by Andrew Dalke

Martel-0.3 is now available from http://www.biopython.org/~dalke/Martel/ Martel is a scanner generator for regular languages which uses SAX events to send the parse tree information back to the caller. It's goal is to provide a transition from many existing flat and semi-structured file formats (especially those needed for biopython :) and XML. More details can be found from a recent conference poster available at http://www.biopython.org/~dalke/Martel/BOSC2000.poster/ . Implementation details: o the format description can be a combination of a regular expression strings and Python functions/object: - strings are parsed with a modified version of /F's sre_parse - Python functions are based on Greg Ewing's Plex o the regular expression is turned into an tag table for Marc Andre Lemburg's mxTextTools, which does the actual parsing. o the parser acts like a SAX parser and the resultant tag list is turned into SAX events for the registered handlers. This is the last version of Martel for Python 1.5.2. Changes from 0.2 to 0.3: - Added documentation on the internals and on how to write a parser. - Renamed and moved Generate.StateTable to Parser.Parser - Renamed the various "ContentHandler" to "DocumentHandler." ContentHandler was flat out the wrong method name for SAX. - The parser and exceptions now inherit from the xml.sax.saxlib classes. - To parse a string, use the "parseString" method. The old "parse" method now takes a system identifier string. A system identifier is the SAX way of saying URL. (Note: this will change again with Python 2.0 and the InputSource class.) - The "generate_*" commands now manipulate lists directly instead of passing around 'Parser' objects. - Added parsers which can read a record at a time (ParseRecord and the RecordReader classes.) - Added the optimize module, which does some limited regexp expression cleanups and optimizations. Haven't tested the performance differences yet. - Consistent naming schemes to distinguish between a regexp written as a string (a "pattern"), a parse tree (an "expression") or an mxTextTools table (a "tagtable"). - The "Subpattern" Node was renamed to "Group" for naming consistency with Plex. "Any" was renamed "Dot". "In" was renamed "Any. - Fixed several bugs when translating from an expression tree back to a pattern string. - Added docstrings and comments. - Added type check for the external Plex-like functions, since I was getting annoyed that the error for doing 'Opt("text")' instead of 'Opt(Str("text"))' occured during tagtable generation and was hard to track down. - Moved self test code from the modules into the test/ directory. - Changed the regression code to raise an Assertion error when there was a problem rather than just printing the error and continueing. Andrew Dalke dalke(a)acm.org

20 years, 6 months

[FAQTS] Python Knowledge Base Update -- October 9th, 2000

by Fiona Czuczman

Hi All, It's been a while. Sorry, I've taken a full time job which doesn't give me much time to play with the knowledge base .. This post is simply what's happened since my last post. regards, Fiona Czuczman Unanswered Questions : - How do I change the name of a process (as viewed by 'ps') from Python? - How can I get my _full_ program name (eg. "mylongpythonscript.py") under eg. NT? sys.argv[0] gives me the truncated MS-DOS style, "MYLONG~1.PY" etc. - What are the criteria I should consider when deciding between Numeric Python, Matlab or Octave? - getting full program name via sys.argv[0] on (eg.) NT? - is there code that sends the contents of a directory as a multi-part mime message to e-mail recipients? Answered Questions : - Alternative to os.path.walk - How do I find reference count errors? - Python's big, is there a crisp overview? a quick reference card? a bare bones documentation? - Of what use is 'lambda'? - How do I handle command line args with gnome? ## Unanswered Questions ######################################## ------------------------------------------------------------- How do I change the name of a process (as viewed by 'ps') from Python? http://www.faqts.com/knowledge-base/view.phtml/aid/6149 ------------------------------------------------------------- Adam Feuer ------------------------------------------------------------- How can I get my _full_ program name (eg. "mylongpythonscript.py") under eg. NT? sys.argv[0] gives me the truncated MS-DOS style, "MYLONG~1.PY" etc. http://www.faqts.com/knowledge-base/view.phtml/aid/6159 ------------------------------------------------------------- Jon Nicoll ------------------------------------------------------------- What are the criteria I should consider when deciding between Numeric Python, Matlab or Octave? http://www.faqts.com/knowledge-base/view.phtml/aid/5990 ------------------------------------------------------------- Louis Luang ------------------------------------------------------------- getting full program name via sys.argv[0] on (eg.) NT? http://www.faqts.com/knowledge-base/view.phtml/aid/6158 ------------------------------------------------------------- Jon Nicoll ------------------------------------------------------------- is there code that sends the contents of a directory as a multi-part mime message to e-mail recipients? http://www.faqts.com/knowledge-base/view.phtml/aid/5977 ------------------------------------------------------------- Wolfgang Lipp ## New Entries ################################################# ------------------------------------------------------------- Alternative to os.path.walk http://www.faqts.com/knowledge-base/view.phtml/aid/6000 ------------------------------------------------------------- Daniel Dittmar If you have trouble specifying the correct callback to os.path.walk and would prefer to use an iterator as in for fname in RecursiveFileIterator ('dir1', 'dir2'): process (fname) class RecursiveFileIterator: def __init__ (self, *rootDirs): self.dirQueue = list (rootDirs) self.includeDirs = None self.fileQueue = [] def __getitem__ (self, index): while len (self.fileQueue) == 0: self.nextDir () result = self.fileQueue [0] del self.fileQueue [0] return result def nextDir (self): dir = self.dirQueue [0] # fails with IndexError, which is fine # for iterator interface del self.dirQueue [0] list = os.listdir (dir) join = os.path.join isdir = os.path.isdir for basename in list: fullPath = join (dir, basename) if isdir (fullPath): self.dirQueue.append (fullPath) if self.includeDirs: self.fileQueue.append (fullPath) else: self.fileQueue.append (fullPath) ------------------------------------------------------------- How do I find reference count errors? http://www.faqts.com/knowledge-base/view.phtml/aid/6006 ------------------------------------------------------------- Joseph VanAndel Will Ware <wware(a)world.std.com> (Will Ware posted this on comp.lang.python) Numerous postings to c.l.python, including some of my own, have mentioned the difficulty of debugging memory leaks in C extensions. To old hands this stuff may all be obvious, but we less experienced folk need all the help we can get. This is a helpful trick I've developed using the 1.5.2 codebase. I imagine it would work with the 1.6 and 2.0 codebases as well. The typical problem with memory leaks is mismanagement of reference counts, particularly abuses of Py_INCREF and Py_DECREF, as well as ignorance of the refcount effects of functions like Py_BuildValue, PyArg_ParseTuple, PyTuple/List_SetItem/GetItem, and so forth. The existing codebase offers some help with this (search for Py_TRACE_REFS) but I found it useful to add this function in Objects/object.c, just before _Py_PrintReferences. void _Py_CountReferences(fp) FILE *fp; { int n; PyObject *op; for (n = 0, op = refchain._ob_next; op != &refchain; op = op->_ob_next, /*n++*/ n += op->ob_refcnt); fprintf(fp, "%d refs\n", n); } The difference between this and _Py_PrintReferences is that the latter prints out all objects and their refcounts, in a list that runs many pages. It's obviously impractical to do that at several points in a program that runs in a long loop. But this function will only print the total of all the refcounts in the system, which will allow you to keep track of when you have inadvertently put in something that increases the total refcount every time going thru a loop. In my C extension, I put in the following macros. #if defined(Py_DEBUG) || defined(DEBUG) extern void _Py_CountReferences(FILE*); #define CURIOUS(x) { fprintf(stderr, __FILE__ ":%d ", __LINE__); x; } #else #define CURIOUS(x) #endif #define MARKER() CURIOUS(fprintf(stderr, "\n")) #define DESCRIBE(x) CURIOUS(fprintf(stderr, " " #x "=%d\n", x)) #define DESCRIBE_HEX(x) CURIOUS(fprintf(stderr, " " #x "=%08x\n", x)) #define COUNTREFS() CURIOUS(_Py_CountReferences(stderr)) To debug, I rebuild Python using 'make OPT="-DPy_DEBUG"', which causes the stuff under Py_TRACE_REFS to be built. My own makefile uses the same trick, by including these lines: debug: make clean; make OPT="-g -DPy_DEBUG" all CFLAGS = $(OPT) -fpic -O2 -I/usr/local/include -I/usr/include/python1.5 When I suspect that one of my functions is responsible for a memory leak, I liberally sprinkle it with calls to the COUNTREFS() macro. This allows me to keep track of exactly how many references are being created or destroyed as I go through my function. This is particularly useful in loops where simple mistakes can cause reference counts to grow ridiculously fast. Also, reference counts that shrink too fast (overzealous use of Py_DECREF) can cause core dumps because the memory for objects that should still exist has been reallocated for new objects. ------------------------------------------------------------- Python's big, is there a crisp overview? a quick reference card? a bare bones documentation? http://www.faqts.com/knowledge-base/view.phtml/aid/5976 ------------------------------------------------------------- Wolfgang Lipp, Fiona Czuczman Richard Gruet, rgruet(a)ina.fr; Chris Hoffmann, choffman(a)vicorp.com; Ken Manheimer, ken.manheimer(a)nist.gov; Guido van Rossum, guido(a)CNRI.Reston.Va.US, guido(a)python.org; Tim Peters, tim_one(a)email.msn.com; and the readers of comp.lang.python yes, there is. all of it in one html page, have a look @ http://starship.python.net/quick-ref1_52.html ------------------------------------------------------------- Of what use is 'lambda'? http://www.faqts.com/knowledge-base/view.phtml/aid/6081 ------------------------------------------------------------- Joseph VanAndel Kragen Sitaker <kragen(a)pobox.com> - it is useful to bind arguments, e.g. lambda x, y=zz: do_something(x,y) --- which can be passed as a function in place of do_something. - why would you want to make an indirect function call in the first place? The answer to the second is deep. Of course, you don't ever *need* to make an indirect function call; in procedural programming, you can write code like this: if fcode == 1: do_thing_one(x, y) elif fcode == 2: do_thing_two(x, y) else: complain(fcode) And when you add a new fcode value, you just have to go to every if-elif-elif-else switch and add a new branch. This is kind of bad, in that it scatters information about what fcode==2 means all over the place, and it's likely that it would be handier to have it all in one place. (There's a balance, of course. Sometimes what fcode==2 means has more to do with the code the if-elif thing is in the middle of than with the other branches that also happen when fcode==2.) With object-oriented programming, you can do something like this instead: fcodething.do_something(x, y) and rely on dynamic method dispatch to do the right thing. This has the advantage that you can put all the do_something and do_something_else methods together. With functional programming, instead, you say: fcode(x, y) and just use indirect function invocation to do the right thing. Closures (like lambda x, y, z=foo: do_something(x, y, z)) make it possible to store state in an invocable function, which means that functions (closures, lambdas) become equivalent to objects. There are times when functional code --- passing around lambdas --- is clearer, and there are arguably times when object-oriented code is clearer. Functional code seems to me more likely to be more flexible, but that's kind of a fuzzy statement and could be nonsense. Closures are sort of equivalent to objects with a single method. If you want to do multiple methods, you have to use some parameter to decide which one to invoke. This makes it hard to go from a "single-method" function to a "multiple-method" function --- you have to change every call to it. You can do prototype-based "inheritance" by delegation --- call some "prototype" function if you don't understand the requested method. Here's an example, albeit a specious one, since Python has stacks built in: def stack(op, arg, data, prototype): if op == 'push': data.append(arg) elif op == 'tos': return data[len(data) - 1] elif op == 'pop': data.pop() else: return prototype(op, arg) def make_stack(prototype=lambda op, arg: None): return (lambda op, arg=None, data=[], prototype=prototype: stack(op, arg, data, prototype)) >>> x = make_stack() >>> x('push', 3) >>> x('tos') 3 >>> x('push', 4) >>> x('tos') 4 >>> x('pop') >>> x('tos') 3 >>> x('pop') >>> x('tos') Traceback (innermost last): File "<stdin>", line 1, in ? File "<stdin>", line 2, in <lambda> File "<stdin>", line 5, in stack IndexError: list index out of range >>> x('unknown') >>> def hello(): ... print "hello, world" ... >>> x = make_stack(lambda op, arg: hello()) >>> x('push', 37) >>> x('tos') 37 >>> x('unknown arg') hello, world Just as you can create a lambda that acts like an object, you can create an object that emulates a lambda, simply by creating an object with only one method. Both are kind of awkward. (It gets a lot worse when you start trying to do multiple inheritance with lambdas, closures with objects, etc.) (Also, even without closures, function pointers allow you to simulate objects in languages that really have only structs: C, JavaScript, and Lua come to mind, and of these, JavaScript and Lua have syntactic sugar to make it easier. In C, you have to say things like obj->method(obj, arg).) So both approaches are equally powerful; but both of them are more convenient for expressing certain kinds of algorithms. Lambdas seem to be especially convenient for expressing non-mutative stateless algorithms: map, filter, zip. Objects seem to be especially convenient for writing things with lots of state that can be peacefully extended later on. Lambdas make it possible to have really private attributes, even in libertine[0] languages like Perl, JavaScript, and Python. Well, maybe not in Python --- I don't know it well enough yet, but I wouldn't be surprised if there were a way to get at default argument values ;) In Perl (and, I think, JavaScript), you can use closures to have really private methods, too. This has the unfortunate disadvantage that if the methods are potentially recursive, the closures will have circular references and screw up the reference-counting garbage collection, so you have to deallocate things by hand or leak memory. Sometimes it's clearer to write a function in-line in a lambda, even when you're not binding any data into a closure. "sort" is the usual example; you could define an interface (or protocol) "comparator" consisting of a method "compare" which compared two objects in some user-defined way, and then specify your sort routine to require an object implementing "comparator" which compares objects. This has the disadvantage that the order you want the data in is specified in a different class from the one that wants it sorted, which often means that it's actually in a different file --- by convention or by language requirement. Defining a comparator function is often much easier --- you can usually put it in the same file. But, in many languages, you still have to put it outside of the routine that wants the sorting done --- which means that it's ten, twenty, forty lines away from the sort call. Being able to write the function in-line in a lambda keeps related things together and unrelated things apart, which makes your code easier to read, easier to write, easier to find bugs in, and easier to improve. ------------------------------------------------------------- How do I handle command line args with gnome? http://www.faqts.com/knowledge-base/view.phtml/aid/6117 ------------------------------------------------------------- Joseph VanAndel frederic.gedin(a)free.fr You need to remove from sys.argv the options you processed before invoking the command line option parser from gnome. E.g: import sys,getopt usageStr =\ """-i input_dir [-o output_dir] -r [-- gnome_args] -r specifies real_time mode (default is batch processing) """ # we have to parse arguments before importing gnome.ui, which also wants # to parse arguments. if __name__ == "__main__": global optlist try: optlist, args = getopt.getopt(sys.argv[1:], 'i:o:r') except: detail = sys.exc_info() print detail[0], detail[1] print __doc__ print 'usage : %s %s' % (sys.argv[0], usageStr) sys.exit(-1) # pass remaining arguments to gnome.ui sys.argv = list((sys.argv[0],)) for a in args: sys.argv.append(a) from gnome.ui import * from gtk import * from gnome.config import * # Applications arguments can now be processed from 'optlist'.

20 years, 6 months

PyXML 0.6.1 is released

by Martin von Loewis

Version 0.6.1 of the Python/XML distribution is now available. It should be considered a beta release, and can be downloaded from the following URLs: http://download.sourceforge.net/pyxml/PyXML-0.6.1.tar.gz http://download.sourceforge.net/pyxml/PyXML-0.6.1.win32-py1.5.exe http://download.sourceforge.net/pyxml/PyXML-0.6.1.win32-py2.0.exe http://download.sourceforge.net/pyxml/PyXML-0.6.1-1.5.2.i386.rpm http://download.sourceforge.net/pyxml/PyXML-0.6.1-2.0b2.i386.rpm Changes in this version, compared to 0.6.0: * Support for Python 1.5.2 was restored, as long as no character set recoding is required * The 4DOM package was updated. * Most of the test suite now passes again. * The tutorial was updated. Changes of version 0.6.0, compared to 0.5.x: * The 4DOM package has been integrated into PyXML. * The package supports now SAX2 interfaces in addition to the SAX1 interfaces. Currently, pyexpat and xmlproc can serve as SAX2 drivers. * The proprietary Unicode type has been removed. Instead, PyXML now relies on the standard Python Unicode type. In turn, PyXML 0.6.0 will not work with Python 1.5. It has been tested with 2.0b1. * PyXML now operates on top of the XML package coming in Python 2. The Python/XML distribution contains the basic tools required for processing XML data using the Python programming language, assembled into one easy-to-install package. The distribution includes parsers and standard interfaces such as SAX and DOM, along with various other useful modules. The package currently contains: * XML parsers: Pyexpat (Jack Jansen), xmlproc (Lars Marius Garshol), xmllib.py (Sjoerd Mullender) using the sgmlop.c accelerator module (Fredrik Lundh). * SAX interface (Lars Marius Garshol) * DOM interface (Stefane Fermigier, A.M. Kuchling) * 4DOM interface from Fourthought (Uche Ogbuji, Mike Olson) * xmlarch.py, for architectural forms processing (Geir Ove Grønmo) * Various utility modules and functions (various people) * Documentation and example programs (various people) The code is being developed bazaar-style by contributors from the Python XML Special Interest Group, so please send comments, questions, or bug reports to <xml-sig(a)python.org>. For more information about Python and XML, see: http://www.python.org/topics/xml/ -- Martin v. Löwis http://www.informatik.hu-berlin.de/~loewis

20 years, 6 months

ANNOUNCE: Windows installer for Snack v2.0.1 available

by Kare Sjolander

A self-extracting installer for the Snack Sound Toolkit v2.0.1 and Python 1.6 - 2.0b2 for Windows is now available at http://www.speech.kth.se/snack/ Regards Kare

20 years, 6 months

Announce: ScanErrLog 1.5

by Jerome Alet

Hi, I'm please to announce ScanErrLog version 1.5. This Python module allows people to parse Apache error_log files from one of different possible sources (filename, stdin, python file object), and present their datas in decreasing number of occurences of error messages. This is particularly useful if you want to quickly solve the most annoying problems web surfers encounter visiting your site. CHANGES: ======== - Sample reports are not distributed anymore, because you can now test it online at: http://cortex.unice.fr/~jerome/scanerrlog/TRY-ME.html - Now requires the jaxml Python module, you have to download it separately. - The jahtml Python module is not distributed anymore with scanerrlog, you have to download it separately. - Now uses Distutils as the installation method, see README for details. WHERE TO GET IT: ================ Download it from: http://cortex.unice.fr/~jerome/scanerrlog/ Feedback (ideas, bug reports, patches, not from France wine, etc...) is very welcome. Thank you for reading. -- Jerome ALET - alet(a)unice.fr - http://cortex.unice.fr/~jerome

20 years, 6 months

Python-dev summary: Sept. 16-30

by A.M. Kuchling

Python-dev summary, September 16-30, 2000 ========================================= This two-week period continued to be slow, with only 395K of postings during this span. This is down from 1.5Mb of messages in July and August, which were busy and contentious months. Because the CVS tree is in a code freeze right now, waiting for the 2.0final release, no one can make large changes, and therefore there are no large changes to spur discussion, just bug fixes, about which usually little can be said. Releases ======== 2.0beta2 was released on September 27: http://www.pythonlabs.com/products/python2.0/ List of changes from 2.0b1 to b2: http://www.pythonlabs.com/products/python2.0/news.html The current plan is to issue a release candidate around October 10th. If no problems show up after around a week, this release would become Python 2.0final. So try out beta2, or at least be sure to try the 2.0rc release when it becomes available. Unicode ======= Barry Scott pointed out that the standard library doesn't support Unicode, in general. He ran into a problem with smtplib.py, which would hang if passed a Unicode string. "I found that I had a lot of unicode floating around from win32com that I was passing into wxPython. It checks for string and raises exceptions. More use of encode() and we are up and running. Is this what you expected when you added unicode?" http://www.python.org/pipermail/python-dev/2000-September/016126.html The ultimate cause is that Unicode strings implement the buffer interface, a C-level API letting callers gain access to the internal representation of a string. The buffer interface is used by PyArg_ParseTuple()'s "s#" format sequence, which is used by the .send() method of socket objects, so the net effect is that sock.send(unicodestr) writes the 2-byte representation of the string to the socket: http://www.python.org/pipermail/python-dev/2000-September/016144.html Other matters ============= M.-A. Lemburg wondered if there were any Python parsers which would find multiple errors: "Would it be possible to write a Python syntax checker that doesn't stop processing at the first error it finds but instead tries to continue as far as possible (much like make -k)?" http://www.python.org/pipermail/python-dev/2000-September/016165.html This led to a subthread on compiler generators. Greg Ward talked about ANTLR: "Unlike pgen, ANTLR is LL(k) -- it can support arbitrary lookahead, although k>2 can make parser generation expensive (not parsing itself, just turning your grammar into code), as well as make your language harder to understand. (I have a theory that pgen's k=1 limitation has been a brick wall in the way of making Python's syntax more complex, i.e. it's a *feature*!)" http://www.python.org/pipermail/python-dev/2000-September/016210.html Greg Ward posted the release plans for the Distutils. Distutils 1.0 was released on October 2, and Greg will be on vacation from Oct. 4 through 12th. The Python 2.0 release is planned for October 10th, of course. http://www.python.org/pipermail/python-dev/2000-September/016286.html Distutils 1.0 announcement: http://www.python.org/pipermail/python-dev/2000-October/016412.html Guido suggested adding an .expand() method to the MatchObject class provided by the re module, and /F quickly responded by checking in the change: http://www.python.org/pipermail/python-dev/2000-September/016163.html /F also committed the long-awaited patch to reduce the huge size of the Unicode character database, from over a megabyte down to around 150K. Related Links ============= Temporary archive of python-dev summaries: http://starship.python.net/crew/amk/python/dev/ Python-dev archives: http://www.python.org/pipermail/python-dev/ Python project page on SourceForge: http://sourceforge.net/projects/python Python Enhancement Proposals (PEPs) summarize recent and past proposals for enhancements: http://python.sourceforge.net/peps/ The python-dev summaries are intended to inform the larger Python community of currently ongoing development. To comment on material in this python-dev summary, simply post to comp.lang.python or <python-list(a)python.org>. 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 can share an informed opinion.

20 years, 6 months

Announce: Graphical visualization tools for python and VTK.

by Prabhu Ramachandran

hi, I have developed a visualization application that uses python, Tkinter and VTK (http://www.visualizationtoolkit.org) to visualize scientific data. The package is called VTK-CFD. Though it is called a CFD visualizer it can also be used for non CFD data. VTK-CFD is distributed under the GPL. I have also developed a VTK pipeline browser, using Tkinter. It is included in the VTK-CFD distribution but is also available as a standalone package. The pipeline browser is distributed under the LGPL. Please visit the following urls for details: http://www.aero.iitm.ernet.in/~prabhu/software/vtk/vtk-cfd/ http://www.aero.iitm.ernet.in/~prabhu/software/vtk/vtkPipeline/ thanks, prabhu +---------------------------------------------------------------+ | Prabhu Ramachandran http://www.aero.iitm.ernet.in/~prabhu | +---------------------------------------------------------------+

20 years, 6 months

ANNOUNCE: Distutils 1.0

by Greg Ward

Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward(a)python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig(a)python.org. Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/ And now for something completely different.

20 years, 6 months

functional.py - functional programming in Python

by Bryn Keller

functional.py provides support for a functional style of Python programming. It includes support for closures, curried functions, lazy expressions, lazy tuples (functional programming languages call these lazy lists, but since lists are mutable in Python, tuples are closer in meaning), and lazy equivalents for map, filter, reduce, and zip. Also some higher-order functions for composing functions and such. functional.py is released under the GNU LGPL, and is available on SourceForge at: http://sourceforge.net/projects/xoltar-toolkit/ I have tried to provide a wide range of the tools that a more functional style of Python programming might need, if there are any glaring oversights, please let me know. Bryn Keller xoltar(a)starship.python.net

20 years, 6 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-announce-list October 2000