From python-url at phaseit.net Mon Aug 2 14:19:55 2004 From: python-url at phaseit.net (Peter Otten) Date: Wed Aug 4 16:26:26 2004 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Aug 2) Message-ID: QOTW: "We can't really say much more about thread safety than this, we think the interpreter will survive. The rest is up to the programmer." - Donn Cave "Despite the seemingly endless necessity for doing so, it's actually not possible to reverse-engineer intended invariants from staring at thousands of lines of code (not in C, and not in Python code either)." - Tim Peters Marduk wants to use string formatting with an arbitrary iterable instead of a tuple. Hans Nowak posts a format function that fits the bill. http://groups.google.com/groups?selm=40FF1A61.9050408%40zephyrfalcon.org The release of IronPython 0.6, a Python implementation for .Net and Mono, spawns a broader discussion on the merits of .Net and the Common Language Runtime. http://groups.google.com/groups?threadm=278de0e.0407281353.27b6a457%40posting.google.com http://www.ironpython.com Christopher T. King takes a closer look at Yaroslav Bulatov's attempt to benchmark various approaches to sum many floating point numbers. http://groups.google.com/groups?threadm=Pine.LNX.4.44.0408011847510.21160-100000%40ccc4.wpi.edu Premshree Pillai writes an SMS-to-LiveJournal gateway in Python http://www.livejournal.com/users/premshree/33967.html How would you iterate over a list two consecutive items at a time? That's a the heart of jblazi's question, and it turns out that there are two ways to do it. http://groups.google.com/groups?threadm=pan.2004.07.31.12.27.23.547000%40hotmail.com Patrick Rutledge has written an introduction on how to create games using pygame. http://www.linuxjournal.com/article.php?sid=7694 Is Python fully thread-safe? Jeff Epler is poking fun at the questioner, but Francois Pinard (sorry, no cedilla today) points the discussion into a more serious direction. http://groups.google.com/groups?threadm=mailman.775.1090684870.5135.python-list%40python.org "Btw, thank you for those footnotes in Thinking in Java that encouraged me to try Python :-)" - Dan Bishop. Bruce Eckel, author of "Thinking in Java", asks for a test for string similarity. He receives various answers and a thank-you. http://groups.google.com/groups?threadm=mailman.958.1091195562.5135.python-list%40python.org Dan Sugalski has lost the "Pie-thon" bet to Guido van Rossum that Python would run faster on Parrot, the virtual machine meant to power Perl 6. Images of Guido throwing the pie are finally available. http://www.onlamp.com/pub/wlg/5346 http://www.oreillynet.com/pub/a/oscon2004/friday/index.html ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Brett Cannon continues the marvelous tradition established by Andrew Kuchling and Michael Hudson of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ The Python Business Forum "further[s] the interests of companies that base their business on ... Python." http://www.python-in-business.org The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor@pythonjournal.com and editor@pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python Suggestions/corrections for next week's posting are always welcome. E-mail to should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project. From follower at gmail.com Mon Aug 2 21:04:41 2004 From: follower at gmail.com (Follower) Date: Wed Aug 4 16:27:29 2004 Subject: ANN: libgmail 0.0.7 - Gmail access via Python - Now with FTP Proxy! Message-ID: <3c18c08f.0408021104.1a3b5d5b@posting.google.com> libgmail -- Python binding for Google's Gmail service The `libgmail` project is a pure Python binding to provide access to Google's Gmail web-mail service. The library currently ships with a demonstration utility to archive messages from a Gmail account into mbox files, suitable for importing into a local email client. Also includes a demonstration utility that acts as a SMTP proxy to allow mail to be sent from any standard mail client that uses SMTP (e.g. Mail.app, Mozilla etc). (Now handles attachments.) New demonstration utility to provide access to Gmail message attachments via a download-only FTP proxy--this allows retrieval of suitably marked attachments by a standard FTP client. Utilize more of your Gmail space! License: GPL 2.0 (gmailftpd.py is dual licensed with PSF) Major changes since 0.0.6: * Demo FTP proxy enables marked Gmail message attachments to be download via FTP. * Implemented sending & receiving of message attachments. * Updated SMTP Proxy demo to handle sending attachments. * Added 'getMessagesByQuery' function. Major changes since 0.0.5: (Repeated from last announcement) * Implemented SMTP proxy to enable Gmail to be send with a standard mail client via (E)SMTP. * Extended standard SMTP class to handle ESMTP EHLO & AUTH PLAIN commands. * Utility function '_retrieveJavascript' to retrieve current version of Gmail Javascript file. (By request.)

libgmail 0.0.7 - The `libgmail` project is a pure Python binding to provide access to Google's Gmail web-mail service; includes SMTP & FTP proxies. (03-Aug-04)

From amk at amk.ca Mon Aug 2 21:06:38 2004 From: amk at amk.ca (A.M. Kuchling) Date: Wed Aug 4 16:27:30 2004 Subject: Third Python Bug Day Message-ID: <20040802190638.GA9479@rogue.amk.ca> The third Python Bug Day is coming up this Saturday, August 7 2004. What's a bug day? ================= Participants meet in an IRC channel and collaboratively go through the Python bug database, fixing and closing bugs as they go. You don't need to have previous experience with modifying the Python source; in fact bug days offer a good opportunity to learn the basics by asking questions and working on relatively simple bugs. Bug day participation also helps the developers and makes Python 2.4 a better release by reducing the backlog of bugs and patches. Plus, it's fun! When? ===== This Saturday, August 7, 2004, from 9AM to 5PM EDT (1PM to 9PM GMT). You don't need to be around all day; feel free to stop by for a few hours and contribute. Where? ====== The #python-dev channel on irc.freenode.net. More information ================ For instructions and more information, see http://www.python.org/cgi-bin/moinmoin/PythonBugDay --amk From jonahfish at gmail.com Wed Aug 4 05:23:04 2004 From: jonahfish at gmail.com (jonahfish) Date: Wed Aug 4 16:28:57 2004 Subject: ZPUG DC-Metro, this Thursday @ 7pm Message-ID: <833bbbf90408032023228486ef@mail.gmail.com> The Zope/Python Users Group of DC exists to promote and serve the user and developer community in Washington, DC, for Python, Zope, and Plone. We will hold meetings and networking events, and provide a mailing list to our members. We meet on the first Thursday and third Monday of every month. We've scheduled meetings through the end of September. For now, our meetings are scheduled in downtown DC, in a meeting room at Porter Novelli. ______________________________________________________________ Main presentation: Durus, a new and cool object database from the MEMS Exchange (David Binger). Mini-presentation: Python (ultra) debugger (James Rosey) 8/05/2004 ?from ?19:00 ?to ?21:00 For more info please visit: http://zpugdc.org/meetings/mtg3 Hope to see any and all interested there, Jonah From pilgrim at gmail.com Wed Aug 4 16:32:19 2004 From: pilgrim at gmail.com (Mark Pilgrim) Date: Thu Aug 5 15:24:14 2004 Subject: ANN: Dive Into Python published Message-ID: I am pleased to announce that my Python book "Dive Into Python" is now available on paper, published by Apress and weighing in at 432 pages. http://www.amazon.com/exec/obidos/ASIN/1590593561/ref%3Dnosim/diveintomark20/ More information, and a complete online edition, is available at . Without Apress' financial support, this book would have languished half-written and self-published, full of typos and technical mistakes. Even if you have read the online edition, please consider buying a copy. ===== obligatory back cover blurb follows ===== This is a practical book aimed at busy developers. Every chapter takes a real piece of code and turns it inside out until you can't help but understand it. If there is background information you need to know, you'll learn it along the way. But you won't find long-winded treatises on the aesthetics of API design or the history of computer science. I don't have time for that, and neither do you. And yet, as practical as this book is, there is a touch of passion in it. I fell in love with Python the day I found it. Did I fall in love because of some abstract sense of elegance or style? No, I fell in love because it works and doesn't get in my way. The standard libraries are robust and easy to use. The syntax is not picky or arcane. Developing in Python is like writing pseudo-code that works. After a decade of experience with dogmatic languages, Python is a breath of fresh air. This book covers the basics of Python datatypes, from lists to dictionaries to tuples and beyond. You'll learn about the power of introspection; Python's powerful object model; regular expressions; HTML and XML processing; web services; unit testing; performance tuning; and the newest language features added in Python 2.3: iterators and generators. I hope this book makes you fall in love with Python. But if not, that's okay. You'll learn plenty anyway, and my passion can be enough for both of us. -- Mark Pilgrim From peter at designtheory.org Wed Aug 4 21:47:20 2004 From: peter at designtheory.org (Peter Dobcsanyi) Date: Thu Aug 5 15:24:15 2004 Subject: pydesign 0.4 - combinatorial/statistical design computing Message-ID: The pydesign package is a collection of Python modules and applications to provide a computational framework for working with combinatorial and statistical designs. For download, documentation, installation instructions please visit: http://designtheory.org/software/pydesign/ -- , Peter Dobcsanyi From peter at designtheory.org Wed Aug 4 21:49:06 2004 From: peter at designtheory.org (Peter Dobcsanyi) Date: Thu Aug 5 15:24:15 2004 Subject: ANN: pynauty 0.1 - iso/automorphism for graphs Message-ID: Pynauty is a Python extension module to Brendan McKay's Nauty C procedures. The module provides Python classes to represent graphs and functions for isomorphism testing and computing automorphism groups of graphs. The graphs can be undirected or directed. They can contain loops but no multiple edges. There is always a vertex-coloring associated with them. Ordinary, that is not vertex-colored, graphs can be represented with all vertices having the same color. For download, documentation, installation instructions please visit: http://designtheory.org/software/pynauty/ -- , Peter Dobcsanyi From pje at telecommunity.com Thu Aug 5 04:14:41 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Aug 5 15:24:16 2004 Subject: PyProtocols 0.9.3 Final Message-ID: <5.1.1.6.0.20040804221232.0225d770@mail.telecommunity.com> As there were no further bugs reported for PyProtocols 0.9.3rc2, PyProtocols 0.9.3 final is now available for download. There are no practical changes from rc2, except for file and documentation revision numbers and dates. What is PyProtocols? -------------------- PyProtocols is an extended implementation of PEP 246, adding a new "declaration API" that lets you easily define your own interfaces and adapters, and declare what adapters should be used to adapt what types, objects, or interfaces. Using PyProtocols, you can easily make flexible frameworks that you or other developers can extend without needing to modify the base framework. PyProtocols interfaces can interoperate with those of Twisted and Zope, or can be used entirely standalone. PyProtocols may be used, modified, and distributed under the same terms and conditions as Python or Zope. What's new in version 0.9.3? (Highlights) -------------------------------------------- * Adapter factories can now accept just one argument, the way Twisted and Zope adapters do. * Interface and protocol objects can be called, as a shortcut for 'adapt()' (as Zope and Twisted interfaces do) * You can now more easily install PyProtocols without a C compiler, using the '--without-speedups' option to 'setup.py' (see the README.txt file for details.) * Numerous other bug fixes and enhancements - see CHANGES.txt for details. IMPORTANT: If you are upgrading from a previous version of PyProtocols, please read UPGRADING.txt for important information. Certain rarely-used features have been deprecated, and others have changed slightly. Most users should not experience any problems (except perhaps for DeprecationWarnings), but please be sure to verify this before you upgrade any production code from 0.9.2 to 0.9.3. PyProtocols Resources --------------------- * Upgrading to PyProtocols 0.9.3 (and a look ahead to 1.0) http://peak.telecommunity.com/protocol_api/UPGRADING.txt.html * Detailed Changes for all releases: http://peak.telecommunity.com/protocol_api/CHANGES.txt.html * Release notes, installation instructions, and browsable API docs: http://peak.telecommunity.com/protocol_api/ * Source and Binary Releases: http://peak.telecommunity.com/dist/ * Reference Manual (HTML): http://peak.telecommunity.com/protocol_ref/module-protocols.html * Reference Manual (PDF): http://peak.telecommunity.com/protocol_ref.pdf * Browsable CVS Repository: http://cvs.eby-sarna.com/PyProtocols/ From anthony at interlink.com.au Thu Aug 5 15:10:32 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Thu Aug 5 15:24:16 2004 Subject: RELEASED Python 2.4, alpha 2 Message-ID: <411231C8.3020308@interlink.com.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team and the Python community, I'm happy to announce the second alpha of Python 2.4. Python 2.4a2 is an alpha release. We'd greatly appreciate it if you could download it, kick the tires and let us know of any problems you find, but it is not suitable for production usage. ~ http://www.python.org/2.4 In this release we have new syntax for function decorators, a fix for failing imports so that they don't leave a broken module in sys.modules, a host of updated modules in the standard library (including optparse and doctest) and a large number of other bug fixes and improvements. See either the highlights, the What's New in Python 2.4, or the detailed NEWS file -- all available from the Python 2.4 webpage. There will probably be one more alpha in a few weeks before the first beta a few weeks after that. Please log any problems you have with this release in the SourceForge bug tracker (noting that you're using 2.4a2): ~ http://sourceforge.net/bugs/?group_id=5470 Enjoy the new release, Anthony Anthony Baxter anthony@python.org Python Release Manager (on behalf of the entire python-dev team) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBEjHFDt3F8mpFyBYRAhgXAKCful63a7kAUcHnxFzCZSzq0bmZ7QCfZIqy t/PqaaLcdRL6IVUKPAWiytA= =pQNU -----END PGP SIGNATURE----- From mark at prothon.org Fri Aug 6 04:00:49 2004 From: mark at prothon.org (Mark Hahn) Date: Fri Aug 6 05:46:11 2004 Subject: Prothon is switching to the .NET platform Message-ID: <000401c47b59$32539220$0d01a8c0@MarkVaio> Last week at OSCON, Jim Hugunin showed results from his port of Python to the .NET platform called IronPython. He was able to run Python on the .NET CLR (common language runtime) at speeds rivaling and even surpassing that of the native Python interpreter. This contradicts the prevailing wisdom that .Net is not good for running dynamic languages such as Python and Prothon. This presented an opportunity for Prothon that was too good to pass up. By following in IronPython's footsteps, Prothon will not only be able to run on a stable established interpreter, the CLR, but Prothon will have immediate access to the .NET runtime library of unmatched size. Prothon's previous design plans would not have worked with Python's runtime library and the establisment of its own library would have taken some time. Thanks to the Novell Mono project, which is now at the 1.0 stage, IronPython and Prothon will run on Linux also. Mono is an open-source port of the .NET framework to Linux. The feature set of Prothon will be changed somewhat. Prothon will still be prototype-based. Features relating directly to the interpreter will change of course. Everything in the VanPy talk at the Prothon website (http://prothon.org) in the "engine" section will no longer be available as a feature. The lightweight threads will not be possible, but real co-routines will still be available. The string type will have Unicode encoded as UTF-16 instead of raw 24-bit characters. I will put up a page of changes on the wiki when I know more. Mark Hahn ---- Prothon is a new dynamic object-oriented language that improves upon the excellent language Python. While not compatible with Python, Prothon is close enough for Python code to be easily ported to Prothon. See http://prothon.org. From aahz at pythoncraft.com Fri Aug 6 05:11:05 2004 From: aahz at pythoncraft.com (Aahz) Date: Fri Aug 6 05:46:12 2004 Subject: BayPIGgies: August 12, 7:30pm Message-ID: <20040806031104.GA27907@panix.com> The next meeting of BayPIGgies will be Thurs August 12 at 7:30pm. It will feature general discussion of programming and debugging GUI applications (Qt, Tkinter, wxPython, etc). BayPIGgies meetings are in Stanford, California. For more information and directions, see http://www.baypiggies.net/ Before the meeting, some people meet at 6pm for dinner in downtown Palo Alto. Ducky Sherwood is handling that; please send RSVPs to ducky@osafoundation.org Discussion of dinner plans is handled on the BayPIGgies mailing list. Advance notice: The September 9 meeting agenda has not been set. Please send e-mail to baypiggies@baypiggies.net if you want to make a presentation. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy@lion.austin.ibm.com From oriana.falco at thalesesec.com Fri Aug 6 17:54:23 2004 From: oriana.falco at thalesesec.com (Oriana) Date: Mon Aug 9 02:08:55 2004 Subject: Freeze - Python standalones Message-ID: <808f000f.0408060754.4cc66d51@posting.google.com> Hi! I wrote a Python application that I wish to convert to standalone using Freeze, the problem is that when I try to build the Python source code in Visual C++ I get a prompt asking me for a password. I understand this code is protected but, there's no reason why I shouldn't be able to open the PCBuild\pcbuild.dsw project to build the source code without making any changes. Right? Please help, I need to build this source code in order to use the Freeze application and I can't seem to do it...!!! Thanks in advance, Oriana From johan at gnome.org Sat Aug 7 14:56:29 2004 From: johan at gnome.org (Johan Dahlin) Date: Mon Aug 9 02:08:56 2004 Subject: ANNOUNCE: Gnome-Python 2.0.3 Message-ID: <1091883389.3083.4.camel@johan> Gnome-Python 2.0.3 is now available at: http://ftp.gnome.org/pub/GNOME/sources/gnome-python/2.0/ Gnome-Python provides bindings for the Gnome 2.x development platform libraries. It builds on top of PyGTK, and includes bindings for the following GNOME libraries: * the GConf configuration database * the Bonobo component system * the Gnome-VFS file access library * support for writing panel applets and Nautilus views * the GtkHTML2 widget. * the Gnome-Print print libraries. Gnome-Python requires PyGTK, PyORBit, Python >= 2.2 and the Gnome 2.x development platform to build. PyGtk, Python and Gnome is usually included in your distribution, if not: PyGTK can be found on http://www.pygtk.org/ Python can be found on http://www.python.org Gnome libraries can be found on http://www.gnome.org This release was only possible because of all hard work made by Gustavo Carneiro. Changes since 2.0.2: * Bugfixes - Segfault when importing bonobo modules in emdedded python (Johan, Xavier) - Warning when import gnome module in emdedded python (Xavier) - Fix bonobo.event_source_client_add_listener name and argument parsing (Gustavo) - Accept None for link_id parameter of gnome.help_display (Gustavo) - Segfault in gnome.IconList.get_selection (Scott Tsai) - Fixes for some gnome.vfs_mime_* functions (Scott Tsai) - Fix crash in bonobo.activation.active_server_register (Gustavo) Questions about Gnome-Python can be directed to the PyGTK list: http://www.daa.com.au/mailman/listinfo/pygtk Bug reports should be filed at the Gnome bug tracker: http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-python -- Johan Dahlin From bac at OCF.Berkeley.EDU Sun Aug 8 21:38:25 2004 From: bac at OCF.Berkeley.EDU (Brett C.) Date: Mon Aug 9 02:08:57 2004 Subject: python-dev Summary for 2004-07-16 through 2004-07-31 Message-ID: <41168131.10006@ocf.berkeley.edu> python-dev Summary for 2004-07-16 through 2004-07-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from July 16, 2004 through July 31, 2004. 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 `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) 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 forty-fifth summary written by Brett Cannon (will be going insane when doing the next summary thanks to decorators). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. 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; it's 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 new code; otherwise use the current documentation as found at http://docs.python.org/ . 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/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _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 .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-07-16_2004-07-31.html .. _original text file: http://www.python.org/dev/summary/2004-07-16_2004-07-31.ht ===================== Summary Announcements ===================== Python 2.4a2 is out the door. The usual request for people to run the regression test suite stands. If you have been following the whole decorator syntax bugaboo, realize that I won't summarize it until the next summary (discussion started August 1). But for those of you not in the know, Guido has tentatively accepted the proposed '@decorator' syntax for decorators. This has led to an **immense** explosion in discussion python-dev (over 700 emails already for the next summary and there is still another week to go) on the subject. Basically Guido has said that the community can come up with one other syntax that they like and present that to Guido (already proposed syntaxes are pretty much out of the running for the reasons they were shot down the first time). *Much* more on this subject in the next summary. ======== Summary ======== -------------------------------------------------------------------------------------------------- Makin' bdist_wininst purty and nicer for them non-English speaking folks -------------------------------------------------------------------------------------------------- Thomas Heller asked if some better images for Distutil's bdist_wininst could be used. Some existing images were discussed, but no specific resolution was mentioned in the thread. Walter D?rwald brought up the point that if this was all being worked on he wouldn't mind having Unicode support for things such as author name and such. Thomas and Walter worked on it and that has gone in. Contributing threads: - `bdist_wininst `__ ------------------------------------------------------------------------- Assigning to None a no-no, but still okay for booleans ------------------------------------------------------------------------- Assigning to None is now a SyntaxError instead of a SyntaxWarning. Assignment to True and False, though, is still allowed and probably will not be restricted until Python 3.0 (which will probably have to wait, if Guido's OSCON slides are to be believed, until he retires). The idea of restricting assignment, though, was brought up by Raymond Hettinger. Michael Hudson, though, pointed out it would be difficult and possibly require a special opcode to handle it. Contributing threads: - `Re: [Python-checkins] python/dist/src/Python compile.c, `__ - `None as constant. Still SyntaxWarning `__ ----------------------------------------------------------------- 'as' does not get to be treated with kiddie gloves ----------------------------------------------------------------- Philip Eby asked if 'as' was going to become a keyword. Guido said not now, but in Python 3.0 it will be. Contributing threads: - `"as" to be a keyword? `__ ------------------------------------------------------------- Hopefully you didn't love FCNTL like a child... ------------------------------------------------------------- ... since if you did that kid was a lazy punk that did nothing but cause trouble for Windows users. That's why it got kicked out of the house to never come back. Contributing threads: - `Kill FCNTL.py `__ ------------------------------------------------------------------------------------------------------------------------------------------ How to get Python to compile with Microsoft's free compiler that should just come with the OS standard ------------------------------------------------------------------------------------------------------------------------------------------ 1. Download the free .NET compiler 2. Download the Windows SDK (at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ with only IE) 3. Download Garth's tools to generate a Makefile from the .sln files (at http://mail.python.org/pipermail/python-dev/2004-February/042595.html ) 4. Compile 5. Realize you should be using an OS that doesn't make you go through this many hoops just to have a compiler for your platform Contributing threads: - `Non-Visual Studio builds on Windows XP? `__ --------------------------------------------------------------------------------------------------------------------------------- Tim Peters, whitespace Czar, will break your legs if you mess up the pristine whitespace in CVS --------------------------------------------------------------------------------------------------------------------------------- Tim Peters ran Tools/Scripts/reindent.py over the entire CVS tree and fixed it up. This means you had better not mess up and check in using anything but 4-space indents with no tabs! Contributing threads: - `Fun with whitespace `__ ----------------------------------------------------------- Thread safety == won't blow up in your face ----------------------------------------------------------- Paul Moore pointed out that the documentation for deques in the collections module stated they were thread-safe. It was clarified that the statement meant that internal state would not be corrupted if multiple threads accessed the same object; no guarantee that it isn't accessed in some order or anything. Basically the idea of thread-safety for C code is that it won't lead to the interpreter exploding, nothing more. And you don't even get that guarantee with Python code. Contributing threads: - `Thread safety of deques `__ ------------------------------------------------------------------------ LC_NUMERIC PEP gets a pristine, new PEP number ------------------------------------------------------------------------ Even though the code had already been put into the core, the PEP about LC_NUMERIC and being locale-independent never got a PEP number. Well, now it has one: `PEP 331`_. .. _PEP 331: http://www.python.org/peps/pep-0331.html Contributing threads: - `PEP 331: Locale-Independent Float/String Conversions `__ ----------------------------------------------------------------------- Edward Loper becomes one of us rowdy developers ----------------------------------------------------------------------- And he has already made his initial contribution by helping to rework doctest. Contributing threads: - `Would like to add Edward Loper as a Python developer `__ ------------------------------------------------------------------------------------------------------ Any misbehaving modules during initialization from import now get the boot ------------------------------------------------------------------------------------------------------ Jim Fulton wanted a better way to detect when an import failed thanks to another module being directly imported (e.g., module A imports B which raised TypeError from some initialization code from importing; importing would leave A and B in a shoddy state in sys.modules along with raising TypeError in the import from A instead of raising ImportError). While the latter still occurs, modules are not left in sys.modules in a broken state from exceptions being raised during initialization thanks to Guido and Tim Peters. There was a discussion on circular imports and how to handle those for proper rollback. Two suggestions were taking a snapshot of sys.modules and then restoring with that if something bad happens, and putting in placeholder modules in sys.modules. But this all gets sticky from side-effects that modules can do outside of themselves before they finish importing everyone else. If, for instance, module A, as a side-effect of importation, injected a custom version of len into module B that would make the state of B different than from before the failed attempt to import module A. Now, if module A did this before doing all of its imports it could pull of the len injection but still fail from a bad import. That is not good. Basically the best solution is to not do that; there is a reason you should do all of your global imports as the first thing in a module. Contributing threads: - `Fix import errors to have data `__ ---------------------------------------------------------------------------------------------------------------------------- Stuff about Unicode, state, and how to handle when a stream terminated early; all CJK to me ---------------------------------------------------------------------------------------------------------------------------- Walter D?rwald noticed that codecs.StreamReader.read() would read a few more bytes when it discovered an error. That's bad since there might not be more bytes and continuing once an error has been found is just not right. So he wanted to fix that problem. Unfortunately he and MA Lemburg started to talk and I just couldn't follow everything about stateful and stateless decoders/encoders and the issues; I'm American so Unicode just doesn't fit in my brain well. So if you want to know what conclusions they reached you are going to read the thread on your own. Contributing threads: - `Decoding incomplete unicode `__ ---------------------------------------------------------------------- Use the docs to know what the public API is, people ---------------------------------------------------------------------- Fernando Perez got bit by having something removed from the 'keyword' module that was not part of the documented API. Turns out that running 'help' on the module listed the function in question and so he just went ahead an used it. That's not the right way to go about finding the public API of stdlib code. Always follow the documentation. If it is not listed there don't expect it to be there in the next version. While we try not to yank stuff out needlessly and will tweak things to be nice on occasion, we make no guarantees on stuff not listed in the API. The next best thing is what is listed in __all__ for a module. Since that is explicitly listed that usually can be considered part of the API. And lastly, anything starting with an underscore is off limits in terms of promises of keeping it around. Luckily Skip Montanaro applied a patch for pydoc to have it only list stuff in modules as specified by __all__, so it's a little safer out there. But the actual documentation is still king. Contributing threads: - `Rationale behind removing kwdict from keyword.py? `__ ------------------------------------------------------- Linking against static builds on Windows ------------------------------------------------------- Thomas Heller pointed out that one couldn't dynamically link against a statically built Python interpreter DLL. He and Martin v. L?wis discussed various ways to try to get this to work, but it doesn't appear they came up with one. Contributing threads: - `Static builds on Windows `__ From python-url at phaseit.net Mon Aug 9 15:08:09 2004 From: python-url at phaseit.net (Peter Otten) Date: Mon Aug 9 15:20:13 2004 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Aug 9) Message-ID: QOTW: "That's a healthy relationship with a language, I feel, when the language and me are struggling with the same problems." - Harald Massa "Fight the trend to add silly disclaimers everywhere!" - GvR Tim Peters helps Kenneth McDonnald over the hurdle of initializing subclasses of an immutable type like str. http://groups.google.com/groups?selm=mailman.1322.1091854312.5135.python-list%40python.org Jeff Epler digs into the C Source to find out why overriding file.write() has no effect on the print statement. http://groups.google.com/groups?threadm=7d04h0dskqbdf2j1f8429726j766mnhrhj%404ax.com You could assure Zeljko Vrba, the "Perl expert wanting to learn Python", that he has already made the hardest step in the new direction. http://groups.google.com/groups?c2coff=1&threadm=slrncguga2.fcp.mordor%40fly.srk.fer.hr --- "@ looks like a friendly little womb, with a happy little birth canal, out of which is born a single pure expression" - Tim Peters The appearance of decorators - a mechanism for wrapping functions and adding attributes to them - in the second alpha of Python 2.4 stirs a heated discussion. Many do not like the introduction of a new symbol, "@" aka "pie", for decoration, or see the chosen one as too "visually dense" (obtrusive) - or just plain ugly. Barry Warsaw weighs alternative symbols. http://mail.python.org/pipermail/python-dev/2004-August/047133.html Christopher T. King argues that the new feature is trying to be all things to all people. http://groups.google.com/groups?selm=Pine.LNX.4.44.0408050856390.31290-100000%40ccc9.wpi.edu Steven Bethard explores the option space, i. e. all aspects of decorator syntax that can be chosen independently. http://groups.google.com/groups?selm=d11dcfba.0408060919.10c7cdd6%40posting.google.com Of course the discussion has been going on among Python's developers for a while and the PEP maintainers who where left behind at some point are struggling hard to update it to the current state of affairs. http://www.python.org/peps/pep-0318.html http://www.python.org/cgi-bin/moinmoin/PythonDecorators I cannot close this section without at least one use-case, so have a look at Michele Simionato's multimethod enhancement, building on code by Howard Stearns and - decorators. http://groups.google.com/groups?threadm=4edc17eb.0408080531.6f8963f9%40posting.google.com (Now be prepared for a more down-to-earth Python-URL next week) --- Let's go back to the "other" pie. Even the most peaceful Pythoneer will ponder "pie-decorating" the author of this short pie-thon report. It's fun, though. http://www.ntk.net/2004/08/06/ ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Brett Cannon continues the marvelous tradition established by Andrew Kuchling and Michael Hudson of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ The Python Business Forum "further[s] the interests of companies that base their business on ... Python." http://www.python-in-business.org The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor@pythonjournal.com and editor@pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python Suggestions/corrections for next week's posting are always welcome. E-mail to should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project. From tim at zope.com Mon Aug 9 23:39:40 2004 From: tim at zope.com (Tim Peters) Date: Tue Aug 10 15:25:14 2004 Subject: ZODB 3.2.3 released In-Reply-To: Message-ID: <20040809213939.23E9B3B8038@smtp.zope.com> I'm pleased to announce the release of ZODB 3.2.3. This corresponds to the ZODB (and ZEO) that shipped with Zope 2.7.2. Upgrading to ZODB 3.2.3 is recommended for all users. You can download a source tarball or Windows installer from: http://zope.org/Products/ZODB3.2 This is a pure bugfix release. The most prominent fix since ZOBD 3.2.2 is in ZEO's treatment of temporary cache files. See the news file for details: http://zope.org/Products/ZODB3.2/NEWS Note that ZODB 3.2.3 does not support Zope X3 (Zope 3 requires ZODB 3.3 -- as will Zope 2.8). From amk at amk.ca Tue Aug 10 00:39:31 2004 From: amk at amk.ca (A.M. Kuchling) Date: Tue Aug 10 15:25:14 2004 Subject: Outcome of third Bug Day Message-ID: <20040809223931.GA11572@rogue.amk.ca> The Python Bug Day held this past Saturday went well. 19 bugs and 12 patches were closed. That's not as good as the first bug day (30 bugs), but is competitive with the second (18 bugs, 21 patches). Lots of the easy bugs have been cleaned out, I expect, so each remaining bug takes more time to fix. Sadly, while a request on python-dev earlier in the week resulted in much higher participation by people with CVS commit privileges, there weren't as many non-committer people around as on the previous bug days. During the course of the day, Armin Rigo wrote a nifty IRC bot that takes an SF bug/patch ID and returns the title; taking an example from the transcript: 20:53:56 Looking at #777659. 20:53:57 * sf_number bug 777659 - Uninitialized variable used in Tools/faqwiz/faqwiz.py I won't be running a bug day in September; if someone else wants to arrange it, please feel free. Otherwise, the next bug day will probably be in October; watch comp.lang.python.announce for an annoucement in early October. --amk From ianb at colorstudy.com Tue Aug 10 05:29:46 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Tue Aug 10 15:25:15 2004 Subject: Chicago Python User Group Meeting, August 12 Message-ID: <4118412A.6080106@colorstudy.com> The Chicago Python User Group, ChiPy, will have its next meeting on Thursday, August 12, starting at 7pm. For more information on ChiPy see http://chipy.org Aaron Lav will talk about Nevow (http://nevow.com) and his Nevow-based photo album which arranges plant photos by the standard taxonomy (e.g by family, genus, etc.) Nevow is a web application construction kit, itself built on Twisted (http://twistedmatrix.com), a pure-Python server framework. There will also be time to chat, and we've been spending a bit of time each meeting exploring the standard library and talking about what people are doing with Python. We encourage people at all levels to attend. Location -------- This month we will be meeting in downtown Chicago, at SMS: 444 N. Michigan Ave, floor 28. It's two blocks from the Grand Avenue exit on the red line. (Note: you will have to sign in at the front desk.) See the website for more information (http://chipy.org). There will be wireless connectivity. About ChiPy ----------- This will be ChiPy's third meeting. We meet once a month, on the second Thursday of the month. If you can't come this month, please join our mailing list: http://lonelylion.com/mailman/listinfo/chipy From edreamleo at charter.net Wed Aug 11 15:47:40 2004 From: edreamleo at charter.net (Edward K. Ream) Date: Wed Aug 11 16:49:35 2004 Subject: ANN: Leo 4.2 beta 3 now available Message-ID: <10hk8s1g5o3jnd4@corp.supernews.com> Leo 4.2 Beta 3 is now available at http://sourceforge.net/projects/leo/ This version of Leo is feature complete. Leo's core code has been stable for several months. To do: most plugins work with the new code base, but other plugins need some more work. Late note: the *nix install script will work better with *nix line endings :-) The highlights of Leo 4.2: - @thin trees make Leo much more friendly to cvs. - Leo's data structures have been reorganized to make outline operations significantly faster. All old script still work. - @test and @script nodes convert scripts to unit tests automatically. Converting scripts to unit tests now takes a few seconds! - A faster and more robust spell checker plugin. (requires Python 2.3) - Leo is now much more friendly to using spaces instead of tabs. - The Execute Script command reports erroneous lines more clearly. - The Perfect Import feature guarantee that Leo imports file exactly. - Leo draws large outlines more quickly with less memory used. - Dozens of other improvements. Quotes of the month ------------------- "I'm a newbie to Leo(a couple of weeks) and I feel addicted to programming again...in fact it has resurrected a dead project of mine :) The outline has proven most liberating in terms of testing ideas out. Thanks a lot!" -- anon "Wow, wow, and wow. I just started using Leo about a month ago..Now I finally understand how to use clones and I realized that this is exactly how I want to organize my information. Multiple views on my data, fully interlinkable just like my thoughts...Thanks for a great tool! -- anon "I *LIKE* it; I was amazed at how [different the Leo] experience was compared to flat-filing. It was almost Forth-like in the way that it was possible to work top-down or bottom-up at will (I believe this is the key to its strength, btw)." --Tarvin Rhodes What is Leo? ------------ - A programmer's editor, an outlining editor and a flexible browser. - A literate programming tool, compatible with noweb and CWEB. - A data organizer and project manager. Leo provides multiple views of projects within a single outline. - Fully scriptable using Python. Leo saves its files in XML format. - Portable. leo.py is 100% pure Python. - Open Software, distributed under the Python License. Leo requires Python 2.2.1 or above and tcl/tk 8.4 or above. Leo works on Linux, Windows and MacOs X. Links: ------ Leo: http://webpages.charter.net/edreamleo/front.html Home: http://sourceforge.net/projects/leo/ Download: http://sourceforge.net/project/showfiles.php?group_id=3458 CVS: http://sourceforge.net/cvs/?group_id=3458 Wiki: http://leo.hd1.org/ Edward K. Ream August 10, 2004 -------------------------------------------------------------------- Edward K. Ream email: edreamleo@charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html -------------------------------------------------------------------- From REMOVE_cuni at programmazione.it Wed Aug 11 20:54:42 2004 From: REMOVE_cuni at programmazione.it (Antonio Cuni) Date: Thu Aug 12 00:59:08 2004 Subject: [ANN] WebFormKit 0.1 released. Message-ID: WebFormKit is a Webware's plugin that helps programmers to develop Web based application. One of the key concept of WebFormKit is the strong separation between presentation logic and business logic: a page is generally composed by an XML file containing the structure of the document and a Python file, containing the programming logic underlying the page. It is event-driven, meaning that developing WebFormKit's application is in a way similar to developing "standard" GUI application. Finally, WebFormKit is very extensible: developers can easly write their own custom extensions that will fit perfectly in core APIs. You can download WebFormKit from http://webformkit.sourceforge.net From aahz at pythoncraft.com Thu Aug 12 00:57:42 2004 From: aahz at pythoncraft.com (Aahz) Date: Thu Aug 12 00:59:09 2004 Subject: REMINDER: BayPIGgies: August 12, 7:30pm Message-ID: <20040811225742.GA16650@panix.com> The next meeting of BayPIGgies will be Thurs August 12 at 7:30pm. It will feature general discussion of programming and debugging GUI applications (Qt, Tkinter, wxPython, etc). BayPIGgies meetings are in Stanford, California. For more information and directions, see http://www.baypiggies.net/ Before the meeting, some people will meet at 6pm for dinner at Patxi's Pizza. Ducky Sherwood is handling that; please send RSVPs to ducky@osafoundation.org by 4pm Thurs. Discussion of dinner plans is handled on the BayPIGgies mailing list. Patxi's Pizza (next door to Jing Jing) http://www.patxispizza.com/ 441 Emerson Street Palo Alto, California 94301 650-473-9999 (Pizza takes 30-40 minutes to arrive after ordering; be sure to arrive on time or order ahead.) Advance notice: The September 9 meeting agenda has not been set. Please send e-mail to baypiggies@baypiggies.net if you want to make a presentation. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy@lion.austin.ibm.com From tim at zope.com Fri Aug 13 20:41:49 2004 From: tim at zope.com (Tim Peters) Date: Fri Aug 13 22:26:55 2004 Subject: ZODB 3.3b2 released In-Reply-To: Message-ID: <20040813184147.EBE953B805B@smtp.zope.com> I'm pleased to announce the release of ZODB 3.3b2. This corresponds to the ZODB (and ZEO) that will ship with ZopeX3-3.0.0b2. Note that ZODB 3.3b2 cannot be used with any released version of Zope2. You can download a source tarball or Windows installer from: http://zope.org/Products/ZODB3.3/ This is a pure bugfix release. See the news file for details: http://zope.org/Products/ZODB3.3/NEWS.html From msjogren at gmail.com Fri Aug 13 21:41:37 2004 From: msjogren at gmail.com (=?ISO-8859-1?Q?Martin_Sj=F6gren?=) Date: Fri Aug 13 22:26:56 2004 Subject: [ANN] pyOpenSSL 0.6 released Message-ID: <1e1bb1f00408131241676cf8c1@mail.gmail.com> After a long hiatus during which I've somehow managed to write a master's thesis, I'm pleased to announce the release of pyOpenSSL 0.6. There are bug fixes, the most important being support for the cyclic GC, which got rid of a few nasty memory leak bugs. There is added functionality to some types, there is brand new support for the Netscape SPKI extensions and much more. Much of this comes from contributions from the user base and I'm really happy about that. If anybody would like to contribute Windows binaries, I'd be happy to put them on the sourceforge project page, I have no possibility to compile them myself. Grab the release from http://sourceforge.net/project/showfiles.php?group_id=31249&package_id=23298&release_id=260375 /Martin Sj?gren From joel at joelburton.com Fri Aug 13 22:08:17 2004 From: joel at joelburton.com (Joel Burton) Date: Fri Aug 13 22:26:56 2004 Subject: Zope/Python Users of Washington, DC: Zope/Plone Meeting on 8/16 Message-ID: <411D1FB1.6080105@joelburton.com> ZPUGsters & everyone else: The next meeting of the Zope/Python Users Group of Washington, DC, is next Monday, at 7pm, at the usual location in downtown DC. Our topics are: - Cyrus Karbassiyoon, on the intranet he just launched for Gentry Locke Rakes and Moore LLP. He'll be talking about why they chose Plone, how they built the site, and what they learned. This should be excellent if you're considering Plone for upcoming projects. - Paul Boos, of SAIC, will be talking about the general process of getting software certified for governmental use, and about general tips for bidding on or performing government work. Upcoming schedule: ================== We have meetings twice a month: the first Thursday (a Python-in-general meeting) and the third Monday (Zope/Plone/other Python-based-webapps-specific). Our future meetings are: - Th, 9/2 (Python meeting). Topics TBD. - Mo, 9/20 (Zope/Plone meeting). Topics TBD. - Th, 10/7 (Python meeting). Topic: "Using Spambayes in a Unix/Linux environment for the Python-Oriented" (Scott Burns). Mini-presentation: TBD. - Mo, 10/18 (Zope/Plone meeting). Topic: TBD. Mini-presentation: "Re-cap of Plone Conference II" (Joel Burton). All meetings are in downtown DC, convenient to mass transporation, at 7pm. Directions at http://zpugdc.org/meetings/pn. Presenting ========== Please consider signing up for a presentation; we'd love to hear about projects you're working on, features of Zope/Plone/Python you use, interesting add-ons you want to talk about, or nearly anything else of interest to us! Also, if you haven't done so, please sign-up for our mailing list at http://zpugdc.org. Thanks, - j. Joel Burton, for the Zope/Python Users Group of DC info@zpugdc.org From robin at alldunn.com Sat Aug 14 10:30:19 2004 From: robin at alldunn.com (Robin Dunn) Date: Sun Aug 15 17:00:16 2004 Subject: ANN: wxPython 2.5.2.7 Message-ID: <411DCD9B.30108@alldunn.com> Announcing ---------- I'm pleased to announce the 2.5.2.7 release of wxPython, now available for download at http://wxpython.org/download.php or https://sourceforge.net/project/showfiles.php?group_id=10718&package_id=10559&release_id=260444 What is wxPython? ----------------- wxPython is a GUI toolkit for the Python programming language. It allows Python programmers to create programs with a robust, highly functional graphical user interface, simply and easily. It is implemented as a Python extension module that wraps the popular wxWidgets cross platform GUI library, which is written in C++. wxPython is a cross-platform toolkit. This means that the same program will usually run on multiple platforms without modifications. Currently supported platforms are 32-bit Microsoft Windows, most Linux or other Unix-like systems using GTK or GTK2, and Apple Macintosh OS X. Changes in 2.5.2.7 ------------------ The changes in this version are too numerous to list here, please see the following web sites for more details. If you are upgrading from a previous version then please do read the MigrationGuide fully before getting started as there are some backwards incompatible changes. http://wxpython.org/recentchanges.php http://wxpython.org/migrationguide.php New Docs -------- Also available with this release is a sneak peak at the work in progress for the new Python-specific reference documentation. While much of the content is not yet present, the docs are still usable, and in fact helpful since they already accurately document what classes and methods are present in wxPython and what the parameter names are. You can download a tarball containing the new docs by following the wxPythonNewDocs link on the download page, and it can also be accessed online at http://wxPython.org/docs/api/. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From srichter at cosmos.phy.tufts.edu Sun Aug 15 20:48:29 2004 From: srichter at cosmos.phy.tufts.edu (Stephan Richter) Date: Wed Aug 18 16:25:23 2004 Subject: Zope X3 3.0.0 beta 3 released Message-ID: <200408151448.29943.srichter@cosmos.phy.tufts.edu> The Zope 3 development team is proud to announce the third beta release of Zope X3 3.0.0. Zope X3 is the next major Zope release and has been written from scratch based on the latest software design patterns and the experiences of Zope 2. The "X" in the name stands for "experimental", since this release does not try to provide any backward-compatibility to Zope 2. Downloads http://zope.org/Products/ZopeX3 Installation instructions for both Windows and Un*x/Linux are now available in the top level README.txt of the distribution. The binary installer is recommended for Windows. Changes since beta 2 - Updated to use ZODB 3.3b2. - Reviewed security and fixed many outstanding open issues. This required some rearranging and writing of security-related code. - Removed several uses of 'removeAllProxies()' as this is considered a bad coding practice. - Added 'zope.security.proxy.removeSecurityProxy()' function to replace 'zope.security.proxy.trustedRemoveSecurityProxy()'. - Implemented rdb:gadflyRoot directive. You are now able to specifically point to a directory that should contain the gadfly databases. - When browsing the source code via the API doc tool's Class Browser, ZCML files are now shown as well. When viewed, a marked up version of the ZCML code is shown with links to other parts of the documentation. - Resolved or otherwise dealt with issues 112, 122, 130, 133, 139, 162, 190, 194, 202, 203, 211, 212, 219, 220, 221, 225, 228, 231, 234, 235, 238, 239, 245, 247, 249, 251, 252, 253, 255. - Fixed various bugs in the API doc tool. - Factory IDs have to be real IDs now, i.e. either a dotted name or a URI. - Cleaned up much of the source code. Now every module should have a module doc string with a title and 'id' tag in it. Goals The API is frozen for X3.0.0. We would like to ask all people to test this release and report any bugs or mis-behaviors! This might be the last beta release! The entire beta period will likely last for about 2 months. During this time we will try to complete the following tasks: - Fix outstanding bugs. - Optimize critical components to speed up the system. - Write and update documentation. - Add and complete translations. - Remove as many XXX comments as possible. Though much progress has been made since the second beta, there are still tasks to be completed! Even if you are not a programmer, you can help! Please send any bug reports and comments to zope3-dev@zope.org! Thank you very much in advance for your help! Contributors Jim Fulton, Fred Drake, Dmitry Vasiliev, Philipp von Weitershausen, Stephan Richter, Garrett Smith, Tim Peters. Thanks to everyone! From follower at gmail.com Tue Aug 17 18:13:33 2004 From: follower at gmail.com (Follower) Date: Wed Aug 18 16:25:23 2004 Subject: ANN: Python Decrypt PDF script -- builds on pdftools Message-ID: <3c18c08f.0408170611.655d9ba@posting.google.com> Hi, I wanted to extract the meta-data from an encrypted/protected PDF file and could not find any Python scripts to do this. So, I decided to write something myself, the result follows. This demonstration utility requires the `pdftools` files from but the decryption functions themselves should be usable with other Python PDF libraries. Documentation is marginal and all I can say is that worked on the three PDF files I tested it on... :-) --Phil. P.S. The usual Usenet-mangling warning applies--yeah, I know--I should put it up on a web site somewhere... :-) #!/usr/bin/python # # Decrypt PDF Info # # Decrypts PDF files and displays meta-data associated with them. (If the # file isn't encrypted the information is displayed as is.) # # The results are similar to xpdf's `pdfinfo` utility. # # It should be possible to decrypt all of the objects contained # in the PDF, but this only reads the Document Information Dictionary. # # (Note: All the PDF handling is provided by `pdftools`, this just adds # the ability to deal with encrypted PDF files.) # # Requires: # + pdftools # # # Based on: # + `pdfdecrypt.pl` # [PDFPL] # # Incorporates: # + RC4 from CipherSaber implementation by Ka-Ping Yee # # # References: # + [PDFE] # # Author: # follower@myrealbox.com (Standing on *many* shoulders...) # import sys import md5 import struct from pdftools import PDFdocument def arcfour(input, key): """ Perform the ARCFOUR (RC4) algorithm on a given input list of bytes with a key given as a list of bytes, and return the output as a list of bytes. (From CipherSaber implementation by Ka-Ping Yee ) """ i, j, state = 0, 0, range(256) for i in range(256): j = (j + state[i] + key[i % len(key)]) % 256 state[i], state[j] = state[j], state[i] i, j, output = 0, 0, [] for byte in input: i = (i + 1) % 256 j = (j + state[i]) % 256 state[i], state[j] = state[j], state[i] n = (state[i] + state[j]) % 256 output.append(byte ^ state[n]) return output _passwordPad = [ 0x28, 0xbf, 0x4e, 0x5e, 0x4e, 0x75, 0x8a, 0x41, 0x64, 0x00, 0x4e, 0x56, 0xff, 0xfa, 0x01, 0x08, 0x2e, 0x2e, 0x00, 0xb6, 0xd0, 0x68, 0x3e, 0x80, 0x2f, 0x0c, 0xa9, 0xfe, 0x64, 0x53, 0x69, 0x7a] passwordPad = "".join([chr(b) for b in _passwordPad]) def calculateFileKey(fileId, ownerHash, userHash, permissions, userPassword = ""): """ Calculates the file key for the document as described in references (see [PDFE] and [PDFPL]). """ md = md5.new() md.update((userPassword + passwordPad)[:32]) md.update(ownerHash) md.update(struct.pack("" % sys.argv[0]) doc = PDFdocument(filename) try: fileKey = getFileKey(doc) except NotEncryptedException: fileKey = "" showDocumentInfo(doc, fileKey) From follower at gmail.com Tue Aug 17 18:13:55 2004 From: follower at gmail.com (Follower) Date: Wed Aug 18 16:26:37 2004 Subject: ANN: Python Decrypt PDF script -- builds on pdftools Message-ID: <3c18c08f.0408170611.7c6a4464@posting.google.com> Hi, I wanted to extract the meta-data from an encrypted/protected PDF file and could not find any Python scripts to do this. So, I decided to write something myself, the result follows. This demonstration utility requires the `pdftools` files from but the decryption functions themselves should be usable with other Python PDF libraries. Documentation is marginal and all I can say is that worked on the three PDF files I tested it on... :-) --Phil. P.S. The usual Usenet-mangling warning applies--yeah, I know--I should put it up on a web site somewhere... :-) #!/usr/bin/python # # Decrypt PDF Info # # Decrypts PDF files and displays meta-data associated with them. (If the # file isn't encrypted the information is displayed as is.) # # The results are similar to xpdf's `pdfinfo` utility. # # It should be possible to decrypt all of the objects contained # in the PDF, but this only reads the Document Information Dictionary. # # (Note: All the PDF handling is provided by `pdftools`, this just adds # the ability to deal with encrypted PDF files.) # # Requires: # + pdftools # # # Based on: # + `pdfdecrypt.pl` # [PDFPL] # # Incorporates: # + RC4 from CipherSaber implementation by Ka-Ping Yee # # # References: # + [PDFE] # # Author: # follower@myrealbox.com (Standing on *many* shoulders...) # import sys import md5 import struct from pdftools import PDFdocument def arcfour(input, key): """ Perform the ARCFOUR (RC4) algorithm on a given input list of bytes with a key given as a list of bytes, and return the output as a list of bytes. (From CipherSaber implementation by Ka-Ping Yee ) """ i, j, state = 0, 0, range(256) for i in range(256): j = (j + state[i] + key[i % len(key)]) % 256 state[i], state[j] = state[j], state[i] i, j, output = 0, 0, [] for byte in input: i = (i + 1) % 256 j = (j + state[i]) % 256 state[i], state[j] = state[j], state[i] n = (state[i] + state[j]) % 256 output.append(byte ^ state[n]) return output _passwordPad = [ 0x28, 0xbf, 0x4e, 0x5e, 0x4e, 0x75, 0x8a, 0x41, 0x64, 0x00, 0x4e, 0x56, 0xff, 0xfa, 0x01, 0x08, 0x2e, 0x2e, 0x00, 0xb6, 0xd0, 0x68, 0x3e, 0x80, 0x2f, 0x0c, 0xa9, 0xfe, 0x64, 0x53, 0x69, 0x7a] passwordPad = "".join([chr(b) for b in _passwordPad]) def calculateFileKey(fileId, ownerHash, userHash, permissions, userPassword = ""): """ Calculates the file key for the document as described in references (see [PDFE] and [PDFPL]). """ md = md5.new() md.update((userPassword + passwordPad)[:32]) md.update(ownerHash) md.update(struct.pack("" % sys.argv[0]) doc = PDFdocument(filename) try: fileKey = getFileKey(doc) except NotEncryptedException: fileKey = "" showDocumentInfo(doc, fileKey) From python-url at phaseit.net Wed Aug 18 02:53:58 2004 From: python-url at phaseit.net (Peter Otten) Date: Wed Aug 18 16:26:38 2004 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Aug 18) Message-ID: QOTW "Implementations are always preferred over rhetoric." - Robert Brewer "The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python." - Paul Graham http://www.paulgraham.com/gh.html Colin J. Williams shows Mizrandir how to subclass numarray's arrays. http://groups.google.com/groups?threadm=df3955c3.0408140908.1b9bfb63%40posting.google.com Hoang Do receives various suggestions how to drop into the interpreter from a running script. http://groups.google.com/groups?threadm=mailman.1679.1092569474.5135.python-list%40python.org Kyle Root asks for help arranging a dependency tree of Python modules and receives both theoretical background information on the problem and code implementing a "topological sort". http://groups.google.com/groups?threadm=6ccff37a.0408111831.6eb25a4e%40posting.google.com Timothy Fitz starts a discussion of the differences between Python's generators (an overwhelming success) and coroutines. http://groups.google.com/groups?threadm=972ec5bd.0408141032.385fe115%40posting.google.com Fazer learns that he has competition in the area of scripts that retrieve weather forecasts from the web. http://groups.google.com/groups?threadm=6491b0ab.0408121917.5103b770%40posting.google.com Coming from a C++ background, Olivier Parisy feels uneasy with the use of exceptions to control program flow in non-exceptional situations. Peter Hansen and several others tell him not to worry. http://groups.google.com/groups?threadm=411775aa%240%2417867%24626a14ce%40news.free.fr Roman Suzi has a clear vision of Python 3.0's design process in 2015. http://groups.google.com/groups?selm=mailman.1672.1092553249.5135.python-list%40python.org We resist all urges to say more about decorators or white space. ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Brett Cannon continues the marvelous tradition established by Andrew Kuchling and Michael Hudson of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ The Python Business Forum "further[s] the interests of companies that base their business on ... Python." http://www.python-in-business.org The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor@pythonjournal.com and editor@pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python Suggestions/corrections for next week's posting are always welcome. E-mail to should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project. From sdeibel at wingware.com Wed Aug 18 04:12:13 2004 From: sdeibel at wingware.com (Stephan Deibel) Date: Wed Aug 18 16:26:38 2004 Subject: Python Success Stories Update Message-ID: Hi, I just wanted to let y'all know that the Python Success Stories collection has nine new additions: http://www.pythonology.com/success These 28 stories include significant testimonials that can make it easier to sell technical decision-makers (i.e., your boss) on Python. Whether you're building an online singles community or an air traffic control system -- be sure to check it out! Also In Print ------------- Twelve stories, including the new ones, have been included in the second O'Reilly Python Success Stories booklet, which recently went into print and should be available at O'Reilly exhibit booths at conferences. Thanks, Stephan Deibel -- Wingware Wing IDE for Python Advancing Software Development www.wingware.com From knight at baldmt.com Wed Aug 18 17:55:26 2004 From: knight at baldmt.com (Steven Knight) Date: Fri Aug 20 16:30:23 2004 Subject: ANN: SCons.0.96 adds Fortran 90/95 support, better Qt support, platform-independent file system actions, improved debugging, lots more Message-ID: SCons is a software construction tool (build tool, or make tool) written in Python. It is based on the design which won the Software Carpentry build tool competition in August 2000. Version 0.96 of SCons has been released and is available for download from the SCons web site: http://www.scons.org/ Or through the download link at the SCons project page at SourceForge: http://sourceforge.net/projects/scons/ RPM and Debian packages and a Win32 installer are all available, in addition to the traditional .tar.gz and .zip files. WHAT'S NEW IN THIS RELEASE? IMPORTANT: Release 0.96 contains the following interface changes: - All Builder calls now return a *list* of Nodes, even when the Builder only builds one file. This may require SConscript file changes if you were manipulating the return values from Builders. - The SConsignFile() function now uses a different internal database format by default. This will cause a rebuild when you upgrade to 0.96 unless you modify your SConsignFile() call. - The internal format of .sconsign files has been changed. The change was coded to be backwards-compatible, but there might be corner cases that cause warnings about "ignoring corrupt .sconsign files" and rebuilds when you use SCons 0.96 for the first time in an already-built tree. - The scan_check function that can be supplied to a custom Scanner now must take two arguments, the Node to be checked and a construction environment. It previously only used the Node as an argument. - The internal "node_factory" and "scanner" keyword arguments have been removed from the Builder() function, in favor of separate "target_factory," "source_factory," "target_scanner" and "source"scanner" keywords, which are now documented. - The Scanner add_skey() function has been dropped in favor of using construction variables for the lists of file suffixes known to a Scanner. - File name extensions that contain all digits are now assumed to be version numbers and treated as part of the file basename. - The env.Append() and env.Prepend() methods have been changed to behave like the rest of Python when either argument is a UserList. See the release notes for more information about these changes. This release adds the following new features: - A new --debug=explain option tells SCons to report the reason(s) why it thinks it must rebuild something. - New Moc() and Uic() Builders provide more explicit control over Qt builds, plus new construction variables to control them: $QT_AUTOSCAN, $QT_DEBUG, $QT_MOCCXXPREFIX, $QT_MOCCXXSUFFIX, $QT_MOCHPREFIX, $QT_MOCHSUFFIX, $QT_UICDECLPREFIX, $QT_UICDECLSUFFIX, $QT_UICIMPLPREFIX, $QT_UICIMPLSUFFIX and $QT_UISUFFIX. - Support for Fortran 90 and Fortran 95 has been added. - The newer "ifort" versions of the Intel Fortran Compiler for Linux are now supported. - New functions have been added to return platform-independent Actions that Chmod(), Copy(), Delete(), Mkdir(), Move() and Touch() files and/or directories. - A new Execute() function can now execute Actions directly at SConscript-read time. - A new $RPATH variable has been added that specifies a list of directories for the GNU and IRIX linkers to search for shared libraries. - New $CPPSUFFIXES, $DSUFFIXES, $FORTRANSUFFIXES and $IDLSUFFIXES variables have been added that make it easier to arrange for additional file suffixes to be scanned by the default Scanners. - A new Flatten() function can be used to turn nested lists of Nodes (or other arguments) into a flat list. - A new --debug=presub option prints the commands to be executed before their construction variables are expanded. - A new .win32 Node attribute will expand file names with Windows backslash path separators on any system. - A new ARGLIST variable makes it possible to fetch keyword=value arguments in the order specified on the command line. - Support has been added for the .dylib shared library suffix and -dynamiclib linker option on Mac OS X (darwin). This release enhances the following existing features: - Environment override keywords can now be passed to the Command() Builder. - An emitter argument to a Builder() can now be a list of emitters that will be called in sequence. - The Java() Builder can now take more than one source directory. - Scanners can now use suffix lists from construction variable expansions. - ParseConfig() now recognizes the -Wa, -Wl, -Wp and -pthread flags and adds them to the appropriate variable(s). - Dir (directory) Nodes can now be be created with user-specified Builder objects. - The SConf.CheckLib() method can now search a list of libraries. - The env.WhereIs() method now takes a "reject" argument to weed out specific path names. - When calling Builders, SCons now issues a warning upon use of the keywords "targets" and "sources", which are virtually always typographic errors that otherwise silently (and confusingly) turn into construction variable overrides. - The $ASCOM, $ASPPCOM, $LINKCOM, $SHLINKCOM, $ARCOM, $LEXCOM and $YACCCOM variables all have wrapper Actions by default. This makes it easier to replace the default print behavior with a custom strfunction(). - Individual tools that create libraries now override the default $LIBPREFIX and $LIBSUFFIX values set by the platform. This makes it easier to use Microsoft Visual Studio tools on a CygWin platform. - If Visual Studio is installed, SCons now assumes its C/C++ compiler, its linker and its MIDL compiler are available, too. - SCons now searches for the ICL license file path name in the external environment and the registry before resorting to the hard-coded path name. - When using Visual Studio, SCons now generates the PDB files at link time, not compile time. - Dependency tracking has been modified to eliminate spurious circular dependencies in certain corner cases involving generated header files, and to avoid rebuilding generated .h files when a #included .h file changes. - The internal Task.make_ready() method now creates a list of the out-of-date Nodes for the task for use by the wrapping interface. - A new single_source keyword argument when creating a Builder enforces a single source file on calls to that Builder. The following fixes have been added: - The CacheDir() directory is now created if it doesn't exist. - Construction variables can now be substituted in $LIBS expansions, and $LIBS expansions now properly ignore null library values. - Construction variables that can be searched for libraries now remove .dll files from the list before feeding the list to Win32 compilers. - All *PATH variables can now expand to include Nodes. - The name of a Scanner.Classic instance is now initialized correctly. - SCons now handles dangling symlinks without generating a stack trace. - env.SourceCode() now works properly when called with an individual file name or Node, not just with a directory name or Node. - SCons now handles the lack of an external PATH environment variable. - Use of $MSVS_IGNORE_IDE_PATHS was broken in 0.95 and is now fixed. - The Command() global function now works properly with string actions; this was broken in 0.95. - A bug introduced in 0.95 in building shared libraries under MinGW has been fixed. - SCons now handles null entries (None or '') in tool lists or CPPPATH. - SCons now handles exceptions in thread-safe ways, according to Pythonic standards. - Error messages have been improved when the evaluation of a construction variable expansion yields a Python syntax error. - File names on command lines are now escaped properly when the expansion is concatenated with another string. Performance has been improved as follows: - Node creation has been sped up when calling a Builder by comparing whether environments are the same object, not whether they have equivalent construction variables. - File system Nodes now cache their generated string values after we've finished reading the SConscript() files. - Node lookup has been made slightly more efficient. - Deleting parents' implicit dependencies after a Node has been built has been made more efficient. The documentation has been improved: - The User's Guide has had the following chapters and sections added: A chapter describing how to install Python and SCons; a section describing the declarative nature of SCons functions in SConscript files; a chapter describing File and Directory Nodes and the return values from Builders; a chapter describing the SConf (Autoconf-like) functionality; a chapter describing Java builds. - The early chapters of the User's Guide have been reorganized to better explain concepts for new users (based on input from Robert P. J. Day, many thanks). - User's Guide fixes: the signatures of the various example *Options() calls; triple-quote properly a multi-line Split() example. - Man page additions: an example and explanation of how to use "tools = ['default', ..." when creating a construction environment; a section describing File and Directory Nodes and some of their attributes and methods; a section describing use of the target_factory and source_factory keyword arguments when creating Builder objects. - Man page fixes: formatting typos, misspellings, fix a bad example. ABOUT SCONS Distinctive features of SCons include: - a global view of all dependencies; no multiple passes to get everything built properly - configuration files are Python scripts, allowing the full use of a real scripting language to solve difficult build problems - a modular architecture allows the SCons Build Engine to be embedded in other Python software - the ability to scan files for implicit dependencies (#include files); - improved parallel build (-j) support that provides consistent build speedup regardless of source tree layout - use of MD5 signatures to decide if a file has really changed; no need to "touch" files to fool make that something is up-to-date - easily extensible through user-defined Builder and Scanner objects - build actions can be Python code, as well as external commands An scons-users mailing list is available for those interested in getting started using SCons. You can subscribe at: http://lists.sourceforge.net/lists/listinfo/scons-users Alternatively, we invite you to subscribe to the low-volume scons-announce mailing list to receive notification when new versions of SCons become available: http://lists.sourceforge.net/lists/listinfo/scons-announce ACKNOWLEDGEMENTS Special thanks to Chad Austin, Charles Crain, Tom Epperly, Ralf W. Grosse-Kunstleve, Jonathan Gurley, Bob Halley, Chris Hoeppler, James Juhasz, Chris Murray, Gary Oberbrunner, Simon Perkins, Kevin Quick, Anthony Roach, sam th and Christoph Wiedemann for their contributions to this release. On behalf of the SCons team, --SK From mike at pcblokes.com Fri Aug 20 13:43:01 2004 From: mike at pcblokes.com (Voidspace) Date: Fri Aug 20 16:30:24 2004 Subject: [ANN] includer, proxycleaner and pyhtonutils updates Message-ID: <4125E3C5.40504@pcblokes.com> Several new scripts and module updates over at pythonutils. Visit http://www.voidspace.org.uk/atlantibots/pythonutils.html *NEW* includer.py Version 1.0.0 Adds an INCLUDE command to python scripts for including other modules into them. Lots of nifty features including recursive include, incdir command, will remove relevant import statements and anything under the 'if __name__ ==...' line from included scripts etc.... Useful for distributing modules with several dependencies as a single file. The features mean that it's possible to test a module using normal import statements (of the type from module import....). When you run includer.py, the INCLUDE command causes your included script (minus the test code under a 'if __name__ ==...' line) to be added in *and* the import statements are removed. Using ##INCLUDE is the equivalent of 'from module import *' - avoiding namespace pollution is up to you. python includer.py infilename outfilename Easy hey ! *NEW* proxycleaner.py Version 1.0.0 *NEW* approxClientproxy.py Version 0.1.0 *UPDATED* approx.py Version 0.4.0 approx.py is a cgiproxy for use by those in restricted internet environments. (Work, internet cafes, colleges, libraries, restrictive regimes etc). It is still at beta stage but functional. Cookie handling with ClientCookie now works although support for multiple users and cookie management will be added. Authentication and POST methods are the next issues to work on. DEBUG mode added. proxycleaner.py will 'clean' webpages that have been fetched through approx or the James Marshall perl cgiproxy. Both these scripts modify URLs a pages are fetched through them - this script undoes the modification. approxClientproxy.py is a client script that works in conjunction with approx.py - it runs on your machine. Instead of having approx modify pages you can point your browser at approxClientproxy which handles the communication between itself and approx. Things like javascript, which approx can't modify, work through aPc which transparently mangles *all* access to go through approx... At the moment it's a crude hack of TCPwatch by the Zope corp.. but it works fine and will only improve. Allows transparent unrestricted http access in a restricted environment. *UPDATE* ConfigObj Version 3.2.0 Removed the charmap 'function' that eliminated unicode errors by stamping on unicode. Unicode problems will now raise an exception. If this causes you problems let me know (with examples if possible) and I'll work on the unicode issues. The test for list type entries is not an 'isinstance' test but a 'hasattr' test (append is the attribute tested for). This isn't ubiquitous though. Added the 'stringify' keyword - including changes to the listquote module for this (which is also now a bit faster). fullconfigobj.py is now built using includer.py Uses a newer version of caseless than the previous distribution. Changed license text. *UPDATE* listquote Version 1.1.0 Added handling for non-string elements in elem_quote (optional). Replaced some old += with lists and ''.join() for speed improvements... Using basestring and hasattr('__getitem__') tests instead of isinstance(list) and str in a couple of places. Changed license text. Made the tests useful. *NEW* http_test.py Version 1.2.0 Now at http://www.voidspace.org.uk/atlantibots/recipebook.html (was previously just online in the Python Cookbook) A CGI script that will fetch a URL and display all server headers, saved cookies, the first part of the content (as raw HTML) *and* all the CGI environment variables. Some authentication code as well. Very useful for debugging in various situation or as an illustration of several aspects of basic CGI. # Copyright Michael Foord # Free to use, modify and relicense. # No warranty express or implied for the accuracy, fitness to purpose or otherwise for this code.... # Use at your own risk !!! # E-mail michael AT foord DOT me DOT uk # Maintained at www.voidspace.org.uk/atlantibots/pythonutils.html -- http://www.Voidspace.org.uk The Place where headspace meets cyberspace. Online resource site - covering science, technology, computing, cyberpunk, psychology, spirituality, fiction and more. --- http://www.Voidspace.org.uk/atlantibots/pythonutils.html Python utilities, modules and apps. Including Nanagram, Dirwatcher and more. --- http://www.fuchsiashockz.co.uk http://groups.yahoo.com/group/void-shockz --- Everyone has talent. What is rare is the courage to follow talent to the dark place where it leads. -Erica Jong Ambition is a poor excuse for not having sense enough to be lazy. -Milan Kundera From cnoviello at hotmail.com Sat Aug 21 19:33:28 2004 From: cnoviello at hotmail.com (Carmine Noviello) Date: Mon Aug 23 04:48:26 2004 Subject: [ANN]PyCrash-0.4-pre3 released Message-ID: Hi, a new version of PyCrash is released with new features and improvement.You can download it at: http://sourceforge.net/project/showfiles.php?group_id=98026&package_id=111026&release_id=262214 What's new in this release: * Many bug-fixes expecially related to the Win32 platform. Special thanks to Gary Herron and Michele Petrazzo for their support. Enjoy! _______________________________________________________________________ About PyCrash Project: PyCrash is a Run-Time Exception Dumper which handles uncaught exceptions during the execution of Python programs and collects information about the program context. PyCrash can be very useful in report bug information, because the programmer can easily analyse the program execution context of the crashed application. Major information collected by PyCrash in the crash dump is: - Information about operating system, Python and Python Standard Library version and general information about the program that is crashed (e.g., program name and version, time at witch program started and ended, and so on) - Information about the uncaught exceptions, like the exception type, the context (namely method name) in which the exception occurred and the exception value - General information about variables state - Information about the stack of each thread, like the list of stack frames, the variables value in each stack frame, and so on - General information about source code, like variable and function position in source file that can be useful for the programmer to find quickly bugs in source tree The format of the crash dump file generated by PyCrash is XML, so the programmer can easily read this file to understand why the program is crashed. Now, is also available a GUI browser, named PyCrash Viewer, which allows developers to analyze quickly and easily PyCrash crash dump files in a graphical manner. * Starting from next version, we'll try to document all the PyCrash API More information can be found at: http://www.pycrash.org Thanks!

PyCrash 0.4pre3 - a crash handler for Python written applications. (21-08-04)

From follower at gmail.com Sun Aug 22 15:32:26 2004 From: follower at gmail.com (Follower) Date: Mon Aug 23 04:48:27 2004 Subject: ANN: libgmail 0.0.8 - Gmail access via Python - POP3 Proxy added! Message-ID: <3c18c08f.0408220532.3dc756c@posting.google.com> libgmail -- Python binding for Google's Gmail service The `libgmail` project is a pure Python binding to provide access to Google's Gmail web-mail service. The library currently ships with a demonstration utility to archive messages from a Gmail account into mbox files, suitable for importing into a local email client. Also includes a demonstration utility that acts as a SMTP proxy to allow mail to be sent from any standard mail client that uses SMTP (e.g. Mail.app, Mozilla etc). (Now handles attachments.) New demonstration utility acts as a POP3 proxy to allow mail to be retrieved from any standard mail client that uses POP3 (e.g. Mail.app, Mozilla etc). Features demonstration utility to provide access to Gmail message attachments via a download-only FTP proxy--this allows retrieval of suitably marked attachments by a standard FTP client. Utilize more of your Gmail space! License: GPL 2.0 (gmailftpd.py/gmailpopd.py are dual licensed with PSF) Major changes since 0.0.7: * Fixed login to work again after it was broken by a Gmail change. * Added trash/delete message thread & trash/delete single message functionality. (By request.) * POP3 proxy server demo. (By request.) * Added `GmailLoginFailure` exception to enable tidier handling of login failures (which could be bad username/password or a Gmail change).

libgmail 0.0.8 - The `libgmail` project is a pure Python binding to provide access to Google's Gmail web-mail service; includes SMTP, POP3 & FTP proxies. (23-Aug-04)

From martin at v.loewis.de Mon Aug 23 07:07:09 2004 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon Aug 23 22:25:46 2004 Subject: Mailing list for Python grant proposals Message-ID: <41297b7d$0$13037$9b622d9e@news.freenet.de> After posting the call for grant proposals, at http://www.python.org/psf/call-2004.html we found that submitters still have a number of questions. In order to encourage a public discussion of such questions, we have created a mailing list grants-discuss@python.org, whose info page is at http://mail.python.org/mailman/listinfo/grants-discuss People interested in the call are encourage to subscribe to this list, and post questions and comments. Martin v. L?wis From altis at semi-retired.com Mon Aug 23 17:33:26 2004 From: altis at semi-retired.com (Kevin Altis) Date: Mon Aug 23 22:25:47 2004 Subject: ANN: PythonCard 0.8 Message-ID: PythonCard is a GUI construction kit for building cross-platform desktop applications on Windows, Mac OS X, and Linux. Release 0.8 includes over 50 sample applications and tools to help users build applications in Python, including codeEditor, findfiles, and resourceEditor (layout editor). A list of changes since release 0.7.3.1 is at the end of this message. New samples include ataxx, lsystem, moderator, montyhall, mp3player, reversi, twistedEchoClient. There is also an experimental reStructuredText and HTML editor in the codeEditor directory called restEditor.py. PythonCard requires Python 2.3 or later and wxPython 2.5.2.7 or later. You can download the latest release at: http://sourceforge.net/project/showfiles.php?group_id=19015 Please be sure to look at the migration_guide.txt file in the docs directory if you are upgrading from a previous release. Since the package name has changed, you can continue to use the older PythonCardPrototype package simultaneously with the new PythonCard package, but you must upgrade to wxPython 2.5.2.7. All the information you need about PythonCard can be found on the project web page at: http://pythoncard.sourceforge.net/ The installation instructions and walkthroughs are available on the main documentation page: http://pythoncard.sourceforge.net/documentation.html For a list of most of the samples that have been built with PythonCard and screenshots of them in action go to: http://pythoncard.sourceforge.net/samples/samples.html The kind people at SourceForge host the project: http://sourceforge.net/projects/pythoncard/ If you want to get involved the main contact point is the Mailing list: http://lists.sourceforge.net/lists/listinfo/pythoncard-users Additional Notes: Remember to backup or just delete your old PythonCard directory before installing a new version, so that the old files aren't still in the package directory. If you installed a previous version of PythonCard on Windows using the binary installer, then you should be able to remove the old package via the Add/Remove Programs Control Panel. The distutils installer will put the framework, components, docs, samples, and tools in Lib\site-packages or your Python directory (typically C:\Python23). Of course, on Linux and Mac OS X that path will be slightly different and have forward slashes. Windows users should get a PythonCard menu in the Start->Programs menu with links to the documentation, samples, codeEditor, findfiles, and resourceEditor. The tools and most of the samples will now keep their config and data file info in the "pythoncard_config" directory created by the framework. On Unix, the directory will be ~/pythoncard_config. On Windows, the directory varies as described in the following post: http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/1496793 So, if you run a PythonCard app with any of the runtime tools and select "Save Configuration" from the "Debug" menu, the window positions and sizes of your runtime windows (Shell, Message Watcher, etc.) will be saved in "pythoncard_config/pythoncard_config.txt" not the PythonCard directory. Likewise, when you change the text style used by the codeEditor via the "Styles..." menu item under the "Format" menu, the modification will be saved in "pythoncard_config/stc-styles.cfg" ka --- Kevin Altis altis@semi-retired.com http://altis.pycs.net/ changelog.txt changes since release 0.7.3.1 Release 0.8 2004-08-18 getCommandLineArgs moved to util.py runOptionsDialog moved to templates.dialogs.runOptionsDialog.py dialog.py is now a thin wrapper around wx.lib.dialogs.py all dialog results now use DialogResults class instead of dictionary e.g. result.accepted instead of result['accepted'] see dialogs sample and other samples and tools for examples of change menuDialog changed to insert in place, added default naming based on label changed Calendar component to CAL_SEQUENTIAL_MONTH_SELECTION style added mp3player sample switched to using wx.lib.statbmp.GenStaticBitmap on GTK for Image component Created unit-test facility. defined ignore files for files that should not be imported to check for tests. runAllTests.py runs all tests from the current working directory down, minus ignored. added sample unit test class, in UnitTestSample.py Added two unit tests for LSystem. Pulled out drawAbstractFractal() to allow this. Changed console_server.py and minimalTest.py so that importing the file didn't run code. updated childWindow resource loading to better support standalones refactored resourceEditor to query component spec for default set of attributes in on_componentAdd_command refactored resourceEditor to dynamically build list of available Components instead of using static list converted turtle sample to use Python modules for the script examples fixed resourceEditor so it saves on Run and validates component names changed all occurances of stack in resources to application removed Stack class the application is now the "parent" of the main Background changed __init__ for Background and CustomDialog so they don't take a stack parameter changed childWindow function self.stack.app references are now self.application added lsystem sample added ToggleButton component fixed enableCommand and disableCommand for components & menus added ataxx sample codeEditor now persists all View menu settings added reversi (Othello) sample made spirographInteractive its own sample added restore (inverse of minimize) background window event added twistedEchoClient sample added twistedModel.py module to hold TwistedApplication added redraw method to Widget to simplify immediate redraws added event.target workaround for timer events moved getStyleConfigPath to configuration module renamed stc-styles.rc.cfg to stc-styles.cfg removed unneeded WXMAC code blocks removed get/set methods for position, size, foregroundColor, backgroundColor in Background and CustomDialog and replaced with properties added removeListener method to EventQueue to enable the clean removal of the Message Watcher window when closing app changed codeEditor file dialog default from *.py to *.* fixed Windows border offset in resourceEditor by querying SystemSettings.GetMetric added Bruce Eckel's moderator sample updated Choice, ComboBox, List, RadioGroup to use 'selection' and 'stringSelection' attributes instead of mixed-capability 'selected' and 'selection' attribute see migration guide for more info added templates sub-package to hold common backgrounds and dialogs updated all samples and tools to use lowercase skip() removed CamelCase methods from BitmapCanvas (Draw -> draw) changed Component __init__ init underlying control before Widget class added makeNewId function removed postInit event binding is now part of component init removed getId() from Widget, using GetId() calls in framework *ROWLAND describe binding and spec changes here* added SetValue workaround for TextArea component on Windows removed dispatch.py and moved classes to event.py SetFocus -> setFocus Hide/Show -> visible attribute added visible, position, and size properties to tool windows added Tom Jacobs' montyhall sample added about.py module added About PythonCard dialog to codeEditor and resourceEditor added singleton.py module used by configuration.py, log.py, registry.py, and resource.py removed Ptr classes from isinstance checks removed old addresses052.py sample renamed res.py to resource.py replaced the use of __getattr__ and __setattr__ in Font, StatusBar, and Widget classes with property(), so those classes and components no longer have restrictive attribute access this change also eliminated the need for the _createAttributes and _getAttributeNames methods changed to wx.Frame for runtime tools on Windows to make them the same across platforms removed conditional code check PyCrust since PyCrust is a standard part of wxPython now added createStatusBar method to Background and CustomDialog classes so applications can override that method if they want to use a more complex StatusBar made statusbar.StatusBar a direct subclass of wx.StatusBar renamed PythonCardApp to Application refactored config.py to configuration.py removed PythonCardObject and all references to it removed ObjectMap and all references to it removed ObjectLookup and all references to it changed on_openBackground to on_initialize renamed pom.py to component.py added test.py added timer.py module and simple Timer wrapper added deactivate event to Background updated sound.py to use wx.Sound changed model.py to require Python >= 2.3 and wxPython >= 2.5 converted DC methods to use tuples instead of separate x, y and width, height args changed wx.NULL to None switched to wx package from wxPython import changed to import wx changed wx.wx style prefixes to wx. except for wx.wxEVT constants changed wx.wxHtmlEasyPrinting to wx.html.HtmlEasyPrinting changed default on Message Watcher to show unused events PythonCardPrototype package renamed to PythonCard all references to Prototype updated in source and docs From python-url at phaseit.net Mon Aug 23 21:12:20 2004 From: python-url at phaseit.net (Peter Otten) Date: Mon Aug 23 22:25:47 2004 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Aug 23) Message-ID: QOTW: "Lucky for me I found python before Java took over my brain." - Huy "Python fits my brain" - c.l.py proverb "So as far as I'm concerned, SOAP is not XML, nor is it useful to even a fraction of the degree to which it is destructive." - Uche Ogbuji Over the weekend Andrea Griffini has implemented a toy Basic interpreter in Python, inspired by a post of Leif K-Brooks. A few other languages are also available. http://groups.google.com/groups?threadm=2oo13eFcj548U1%40uni-berlin.de Jeff Epler and Martin von Loewis help Vincent Delft to overcome the lack of encoding-awareness in the zip file format. http://groups.google.com/groups?threadm=4127a6d7%240%244090%24ba620e4c%40news.skynet.be As of June 2004, Pythonology has a few new success stories. http://www.pythonology.com/success Python people are nice, says Andy Todd. http://www.halfcooked.com/mt/archives/000833.html Something new from the decorator front: Paul McGuire initates another decorator poll and a new keyword followed by a suite seems to emerge as a viable contender with a small chance to beat the pie syntax. http://groups.google.com/groups?threadm=t07Vc.1179%24v86.188%40fe2.texas.rr.com Thanks to the work of Michael Sparks building on previous efforts by Mark Russell there is already a patch. Anthony Baxter, the outspoken proponent of the pie syntax, helps with some useful hints, too. http://www.python.org/sf/1013835 Robert Brewer volunteers to "sell" the result to GvR. http://www.aminus.org/rbre/python/pydec.html Too old/too young is no excuse for not learning Python, according to a thread started by Lucas Raab, asking for the "Age of Python programmers" with the only word of caution, "Not yet, but our day will come" being uttered by Robey Holderith. http://groups.google.com/groups?th=5f4805189aa2470d ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Brett Cannon continues the marvelous tradition established by Andrew Kuchling and Michael Hudson of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ The Python Business Forum "further[s] the interests of companies that base their business on ... Python." http://www.python-in-business.org Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor@pythonjournal.com and editor@pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python Suggestions/corrections for next week's posting are always welcome. E-mail to should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project. From bac at OCF.Berkeley.EDU Tue Aug 24 06:50:48 2004 From: bac at OCF.Berkeley.EDU (Brett Cannon) Date: Tue Aug 24 20:37:02 2004 Subject: python-dev Summary for 2004-08-01 through 2004-08-15 Message-ID: <412AC928.7000603@ocf.berkeley.edu> python-dev Summary for 2004-08-01 through 2004-08-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from August 01, 2004 through August 15, 2004. 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 `comp.lang.python`_ (or email python-list@python.org which is a gateway to the newsgroup) 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 forty-sixth summary written by Brett Cannon (two freakin' years doing this; I *am* nuts). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. 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; it's 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 new code; otherwise use the current documentation as found at http://docs.python.org/ . 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/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _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 .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-08-01_2004-08-15.html .. _original text file: http://www.python.org/dev/summary/2004-08-01_2004-08-15.ht ===================== Summary Announcements ===================== Well, I have now been doing the summaries for two years. As has become a yearly tradition, I am offering to pass on the writing of the summaries to someone else. My only requirement is you do a comparable job. You do learn *tons* about Python's internals when you have to research a topic to be able to summarize it. With that said, it is also time for stats on the list to scare away anyone considering taking over this job =) . According to my probably buggy script that I wrote last year, I have read 10,190 emails (this month has already been the busiest month and it is only half over; could set the record for busiest month ever). The people with over 300 emails posted over the year are: 9. Michael Hudson (303) 8. Martin v. Lowis (307) 7. Barry Warsaw (341) 6. Phillip J. Eby (341) # not a typo; same number as Barry 5. Greg Ewing (354) 4. Raymond Hettinger (372) 3. Skip Montanaro (399) 2. Tim Peters (629) 1. Guido van Rossum (1031) These 9 people make up over 40% of all the emails from the past year. Longest threads were: 1. decorate-sort-undecorate (694 emails) 2. Call for defense of @decorators (195 emails) 3. PEP 318: Decorators last before colon (181 emails) 4. redefining is (162 emails) 5. Christmas Wishlist (162 emails) These stats along with the insane amount of email has showed me something; the Summaries have detracted from my participation on python-dev this past year. I have a bigger mouth and more opinions than the number of emails I sent to the list show. This means something has to change, and it isn't going to be my mouth. The Summaries need to change in one of two ways. Option one is that I focus in on certain areas of interest and skip other ones. I have labeled all of the summaries below with what their type is right under the titles. Please email me your top ares of interest. I realize that this month may not be typical but pretty much all areas are covered at least once so at least there is a good taste for the different areas. So, choose from: 1. improvement stuff Pretty much anything that is not a major change to the language/stdlib. Usually something you find out from the Misc/NEWS or the "What's New" doc. 2. how python-dev works Stuff like how python-dev handles things such as the PEP process, coding style, etc. 3. nuggets of info Cool tricks and ideas that come up on the list that the greater world probably does not know. 4. minor language change Stuff that deals with the language changing, but is not significant; such as discussions of existing PEPs. Language evolution stuff (such as decorators) will always be covered so you don't need to vote on that. If people like this first option then I will make sure I cover the area with most votes and everything else is just considered icing. Option two out of all of this is people just say, "summarize what you want, Brett." Then I just cover what I find interesting and just don't worry about covering a specific area. I obviously prefer this option but if people really care about a specific area I want to make sure to cover it. What will most likely happen is I will still cover almost everything but the thoroughness will be lower. I will go more off of memory for example. But something will change. Being on the sidelines for the decorators discussion because I dreaded having to start reading all of those emails in terms of summarizing is not acceptable (and no, I can't just ignore some of them since that is just not how I work). Having to read 1,289 emails for just the first two weeks of this month finally caused me to lose my sanity. Another question becomes whether people miss the "Skipped Threads" feature of the Summaries. If you do let me know and I can go back to doing that by just listing the threads that I don't cover (but with no one-liners probably, but it is possible, or linking to the archives; you would just get the subject line in a long list of threads I didn't bother covering). If that would be *really* helpful then let me know about that as well. ======== Summary ======== -------------------------------------------------------------------------------- Multiple interpreters at a time in a C program kind of broken -------------------------------------------------------------------------------- 3. nuggets of info Philip Eby thought he might have a fix for a known limitation of running multiple interpeters at once (using PyInterpreter_New() ) and having imports not being clearly separated between interpreters. But Martin v. L?wis popped Philip's bubble somewhat by saying that he and some other people viewed multiple interpreter support as inherently broken. Contributing threads: - `Safe to change a thread's interpreter? `__ -------------------------------------------- Another sucker becomes an official developer -------------------------------------------- 2. how python-dev works Sean Reifschneider took the bait to become another one of Guido's minions. Sean has been maintaining the RPM spec files for quite a while. Contributing threads: - `New developer `__ ---------------------------------------- Discovering leaks with a regrtest wrench ---------------------------------------- 1. minor language change Michael Hudson, who found and fixed a bunch of refcount leaks shortly after 2.3 was released, used his magical regrtest patch (which has subsequently been checked in) to hunt down leaks for 2.4 . A bunch of tests were cleaned up to make them not raise false-positives along with fixing some true leaks. Contributing threads: - `refleak hunting season `__ --------------------------------- Another Bug Day has come and gone --------------------------------- 2. how python-dev works The Bug Day held on August 7 led to 19 bugs and 12 patches being closed. You can see the results at http://www.python.org/cgi-bin/moinmoin/PythonBugDayStatus . Feel guilty for not being able to make it? Still want to help? Go to that page to see bugs that could use some squashing that shouldn't be too difficult to deal with. Contributing threads: - `Bug day coming up this Saturday `__ -------------------------------------------------- How to shut a compiler up about an unused variable -------------------------------------------------- 3. nuggets of info Tim Peters had come up with some optimizations for list.pop() that avoided unneeded test+branches. The problem is that it led to a variable possibly being unused. C compilers tend to complain about that and so an initial solution was used. Unfortunately gcc complained about it, and so yours truly came up with one. But that solution was labeled as "perverse" (and it was; total hack solution), so another solution was found thanks to Sjoerd Mullender by just taking the variable and casting it to void. Contributing threads: - `RE: [Python-checkins] python/dist/src/Objects listobject.c, ... `__ ------------------------------------------------------ Variable sequence unpacking assignment shot down again ------------------------------------------------------ language evolution David Cole suggested adding the ability to have sequence unpacking assignment just like \*args for parameters; ``a, b, *c = (0, 1, 2, 3, 4, 5) # a == 0, b == 2, c == (3, 4, 5)``. This idea got a -1 from Guido as not really needed. That reaction makes Guido consistent; the idea was originally shot down back in Nov. 2002; http://www.python.org/dev/summary/2002-11-16_2002-11-30.html#half-baked-proposal-and-in-assignments . If you really like that idea the previous summary contains a function that helps you do this in a way. Contributing threads: - `Tuple/list assignment question `__ ------------------------------------------------------------------------------------- Changing the Big-O complexity for something in the language is now a language feature ------------------------------------------------------------------------------------- language evolution Armin Rigo came up with a way to have string concatenation in a loop (think ``for thing in iter_of_strings: concat_str += thing``) not be a quadratic algorithm thanks to some trickery for ``a = a + b`` and ``a += b`` conditions for strings. The hope was to remove the (commonly considered) wart of having ``"".join(iter_of_strings)`` be the suggested way to concatenate a bunch of strings. But Guido didn't like the patch. His reasoning was that changing something that led to a change in the Big-O complexity of certain algorithms would inherently hurt other implementations of Python when people would start to code specifically for that performance gain. For instance, having Jython be able to pull this trick off is, I believe, near impossible. So, in order to make sure changes like this are considered before applying them, Guido instated a new rule that "implementation features that affect not just the running speed but the O() rate for certain algorithms should be considered language features, because any implementation will be required to implement them in order to ensure code portability" between implementations of Python. In the end, though, this went in with a warning that the speed performance is not portable. It is not to be used in the stdlib ever. Contributing threads: - `Optimized string concatenation `__ - `PEP 0008 confusion - here it is, but don't use it? `__ ------------------------------------------------------------------------------- Bet you didn't think about string interning and how that affects .pyc, did you? ------------------------------------------------------------------------------- 1. minor language change Luckily Martin v. L?wis did. A patch was originally applied to not intern strings representing filenames. Problem is that every code object stores that string, so it increases .pyc files since it has to store multiple copies of that string instead of just one. Contributing threads: - `Re: [Python-checkins] python/dist/src/Python compile.c ... `__ ------------------------------------------------------------------------------ `PEP 324`_ (process - New POSIX process module) != process.py from ActiveState ------------------------------------------------------------------------------ 1. minor language change Guido asked if the APIs between the module proposed in `PEP 324`_ and the process.py module by Trent Mick of ActiveState were compatible. Turns out they are not. Then the discussion went into select(), broken pipes, and other stuff not relevant to the OP. =) .. _PEP 324: http://www.python.org/peps/pep-0324.html Contributing threads: - `PEP 324 (process module) `__ -------------------------------------------------------------------------------------------------------------------------------------------------- Getting it so string literals accept those nutty non-ASCII characters more easily (and getting files to be more upfront about their Unicode-ness) -------------------------------------------------------------------------------------------------------------------------------------------------- language evolution Fran?ois Pinard asked what people thought about two things related to Unicode. First, he thought having a __coding__ attribute for files that contained the encoding of the text would be nice. Martin v. L?wis said it would be possible. MA Lemburg added his vote of support. It has not been implemented to my knowledge yet, though. The second idea was to have a directive of some sort on a per-module basis so that all string literals could be considered in something other than ASCII. Once again Martin said it was doable with MA saying he liked the idea. But it was pointed out that you might as well just use the 'u' in front of strings now. This led to a slight discussion on good i18n practices. Both Martin and MA seemed to suggest that if you are going to be doing most of your work in a single encoding then just use that and declare everything Unicode. ANd if you are going to support a lot of different languages, use gettext and such. Martin also stated it is best to get text into Unicode ASAP and then only convert to the final encoding at the last moment. Contributing threads: - `Python in Unicode context `__ ---------------------------------------------------------------------- An exception is an exception, unless it doesn't inherit from Exception ---------------------------------------------------------------------- language evolution Coming up in a discussion on Unicode of all things, a discussion on moving exceptions over to new-style classes came up. Guido pointed out that moving over to new-style classes would seem to suddenly require that anything passed to 'raise' be a new-style class and that goes against the current acceptance. But in comes Paul Prescod with his argument that exceptions are inherently organized based on inheritance and thus requiring things being passed to 'raise' subclass Exception somewhere is not that big of a thing. Guido really liked that point. So if it goes this way and you don't like it blame Paul (who is a nice guy, so go easy on him =). And then along come Holger Krekel bringing up the point that using exceptions to do non-standard flow control is handy. But the question was asked as to why he couldn't still just subclass Exception? Was it that big of a deal? He admitted it wasn't and said when the name Raisable was suggested that would make it easier. Michael Hudson then came in and wrote up a hacked-up patch to turn exceptions into new-style classes. Most stuff seemed to still work. Python 3 was already going to switch to new-style classes for exceptions and string exceptions have already been deprecated. Now add to the mix the possible requirement that anything passed to 'raise' require a common base class. Contributing threads (note that the thread starts part way in a thread on Unicode and end before the end of the full thread): - `Python in Unicode context `__ ------------------------- Python 2.4a2 out the door ------------------------- language evolution Python 2.4a2 has been released. As usual, please download it and test it with your code along with the regression test suite. Contributing threads: - `trunk frozen for 2.4a2 `__ - `RELEASED Python 2.4, alpha 2 `__ ------------------------------------------------------- Amendment to how to compile with the free .NET compiler ------------------------------------------------------- 3. nuggets of info Nick Coghlan expanded upon my summary on how to compile with the free .NET compiler under Windows at http://www.python.org/dev/summary/2004-07-16_2004-07-31.html#how-to-get-python-to-compile-with-microsoft-s-free-compiler-that-should-just-come-with-the-os-standard . See his email at http://mail.python.org/pipermail/python-dev/2004-August/047215.html on the extra steps. Or just move to another OS. Contributing threads: - `python-dev Summary for 2004-07-16 through 2004-07-31 [draft] `__ -------------------------------------- Darned Solaris, g++, and _XOPEN_SOURCE -------------------------------------- 1. improvement stuff Skip Montanaro discovered that building under Solaris with g++ raised a warning about redefining _XOPEN_SOURCE. pyconfig.h defines it, but apparently so does g++ in order for Solaris' toolchain to expose some code that is only available if it is defined. Martin v. L?wis came up with a couple of suggestions on how to handle this. Skip ended up going with the idea of setting _XOPEN_SOURCE to the same value as it is defined by g++. Contributing threads: - `use of #pragma GCC system_header to suppress _XOPEN_SOURCE warnings `__ ------------------------------------------------------------------------------------- pre-PEP on a function for re that "captures matches for groups that match repeatedly" ------------------------------------------------------------------------------------- 1. minor language change Mike Coleman presented a pre-PEP (newest version at http://mail.python.org/pipermail/python-dev/2004-August/047238.html ) on adding a function to re that would create a tree (in the form of a list) containing all group matches in a string. It got a little support, but the discussion quickly moved over to dreamings of a full-on scanner or parser package for the stdlib. But if the idea of the PEP works for you then speak up on c.l.py . Contributing threads: - `pre-PEP: Complete, Structured Regular Expression Group Matching `__ --------------------------------------- Making ourselves follow the PEP process --------------------------------------- 2. how python-dev works It was noticed early on that the PEP process had broken down for `PEP 318`_ (decorators). What should happen is a PEP gets written (and the author becomes its champion), there is a public discussion, the PEP is updated, that's repeated until it is deemed done, gets get BDFL pronouncement, if Guido okays it the code goes in. Unfortunately the part about updating the PEP didn't really happen. This led to two major things being stated and generally agreed upon. One is that PEPs should not be checked in if the PEP has not been updated. While a minor nit is not a reason to hold back code, not updating after a major public debate is not acceptable. This directly segued into the other point of a PEP needs to have a champion, period. Since the developers on python-dev do not have the time to keep PEPs updated it is up to the PEP champion to make sure it is kept current. If it isn't it is take to mean the champion no longer cares, which means python-dev no longer cares, which means the PEP gets rejected outright. This will also make sure that there is a focus to the design of what the PEP wants and does not lead to a design-by-committee problem. .. _PEP 318: http://www.python.org/peps/pep-0318.html Contributing threads: - `PEP 318, and the PEP process `__ ---------------------------------------------------------------- How to tell Windows from Linux without lifting up anyone's skirt ---------------------------------------------------------------- 3. nuggets of info The question came up on what the best way was to tell what platform you are running on. The answer came down to why you were cared. If it was whether or not you had a specific functionality (or lack thereof), then just test for the functionality. If you had other needs, though, using sys.platform seemed to be the most reliable way (at least for Windows since all of them use 'win32'). Contributing threads: - `Asyncore .set_reuse_addr() on Windows `__ ----------------------------------------- func_name can now have an identity crisis ----------------------------------------- 1. improvement stuff Thanks to the rampant decorator discussion, Skip Montanaro came up with the idea of wanting func_name to be writable. This would allow decorators to wrap a function with another function and yet reset func_name to its original value, thus not having the wrapper function become the prevailing name. Guido liked and Michael Hudson subsequently wrote up `patch #1004703`_. .. _patch #1004703: http://www.python.org/sf/1004703 Contributing threads: - `PEP 318 - writing to func_name attribute `__ ----------------------------------------- statistics.py ain't goin' into the stdlib ----------------------------------------- 1. improvement stuff Raymond Hettinger (at the last Python Bug Day) made the statement that he didn't think 'statistic's should be taken out of the sandbox in CVS and put into the stdlib. He felt that most of the important algorithms were available elsewhere (such as nsmallest and nlargest in the heapq module) and the remaining functions that were not found anywhere were not that critical. He did say, though, he would like to do a calculator module where those remaining functions could go. Contributing threads: - `status of statistics.py? `__ ------------------------------------ Making re.split care about emptiness ------------------------------------ 1. improvement stuff Mike Coleman wrote up a patch for re.split() that AM Kuchling presented to the list. It adds an argument to the function to allow an empty string to be put into the resulting list when a match occurs, even if the match consumes no characters. This allows delimiters used in the regex to still appear in the groups. No decision on the exact semantics of the function, how to handle turning on the new functionality (some say an extra argument, some say adding another bit flag like traditional re arguments), or even if it will be accepted. Contributing threads: - `re.split on empty patterns `__ ---------------------------------------- Pickler's 'bin' argument on its last leg ---------------------------------------- 1. improvement stuff As per `PEP 307`_ (Extensions to the pickle protocol), the 'bin' argument is being upgraded from PendingDeprecationWarning to DeprecationWarning; so it's gone plaid and the only way to stop it is with some emergency change. .. _PEP 307: http://www.python.org./peps/pep-0307.html Contributing threads: - `Pickler()'s bin argument `__ --------------------------------- Some modules are getting the boot --------------------------------- 1. improvement stuff TERMIOS, mpz, statcache, xreadlines and rotor are all being removed. mimify, MimeWriter, and whrandom will raise a DeprecationWarning. rfc822 and mimetools will not be raising DeprecationWarning as specified by `PEP 4`_ since some code in the stdlib still uses it. .. _PEP 4: http://www.python.org/peps/pep-0004.html Contributing threads: - `Removing stuff from 2.4 `__ ------------------------------------------------- Should decimal.Context.copy() be deep or shallow? ------------------------------------------------- 1. improvement stuff Raymond Hettinger brought up the question of whether decimal.Context.copy() should be a deep or shallow copy. While tradition dictates it be shallow based on name, it seems like the functionality should be deep. No one wants context to be shared between number naturally since numbers tend to be viewed as unique things. Staring in 2.4a3 it will be deep unless people come up with reasons to switch it to shallow. Contributing threads: - `decimal.Context.copy() shallow or deep? `__ ---------------------------------------------------------- The dark corners of Python allow you to skip return values ---------------------------------------------------------- 3. nuggets of info Christian Tismer discovered that you can actually stop a return statement from returning if you encase it in a 'finally' block and tweak it slightly (see the OP to get what I mean by this). Turns out this is a reliable feature of Python if you really want to use it. Contributing threads: - `capturing RETURN_VALUE `__ -------------------------------------- Is an int/long combined type worth it? -------------------------------------- language evolution Dmitry Vasiliev pointed out that `PEP 237`_ (Unifying Long Integers and Integers) mentioned that a a new type named 'integer' might be introduced that subclassed both int and long. The discussion waivered between whether it was at all needed, and if it was if it should be a true type or just a tuple containing both types for use with isinstance() . No conclusion was reached in the end. .. _PEP 237: http://www.python.org/peps/pep-0237.html Contributing threads: - `Unifying Long Integers and Integers: baseint `__ -------------------------------------- Should byte arrays be a built-in type? -------------------------------------- language evolution Through the discussion bout having a common type combining int and long a discussion on whether a byte array type should be introduced. The initial suggestion was for it to be practically synonymous with str since str itself stores everything as an array of 8-bit values. The use cases would be for streams and such that just want a stream of bytes with no care for any encoding. Syntactically, having a 'b' and 'B' cookie before literals was suggested. The issue with this, though, is that byte arrays should be mutable, which would make literals that can be mutated, and that is frowned upon by Guido. Semantically, aliasing bytes to the str type was suggested. That was not loved since that could create confusion. Returning an object from 'array' was suggested and seemed okay. In general it seemed this could be useful and could go in 2.5, but nothing for 2.4 . Contributing threads: - `Unifying Long Integers and Integers: baseint `__ ----------------------------- Thar the Windows stack blows! ----------------------------- 1. minor language change Running the new test_compiler test (if you run it with ``-uall`` for regrtest it will recompile the entire stdlib) was leading to an odd failure: the "process on Windows "just vanishes" without a trace, and without an error message of any kind, but with an exit code of 128". After a lot of work put in by a bunch of people (led by Tim Peters) the problem was tracked down to a blown C stack. Turned out that the stack-checking code was not being called frequently enough to pick up the error. The problem with this was that it was leading to odd errors that should have been MemoryError but were manifesting themselves as KeyError. This was because PyDict_GetItem() was failing and return NULL which is the same as signaling the key doesn't exist in the dict. Trick was trying to come up with a good way to deal with this. Adding more calls would be very expensive (reliable way of catching it was sticking a check in pymalloc code) and so that was ruled out. PyDict_GetItem() couldn't change its return value since that would break more code than could be imagined. So, in the end, the stack was increased to 2 MB on Windows. Contributing threads: - `Another test_compiler mystery `__ ------------------------------------------ Someone else falls for the dangling carrot ------------------------------------------ 2. how python-dev works Johannes Gijsbers now has checkin rights. May he close many bugs. Contributing threads: - `New Developer `__ ---------------------------------------------------------- Lying about being in __builtin__ is not always a bad thing ---------------------------------------------------------- 1. improvement stuff James Knight noticed that some objects (mostly C types such as iterators for the built-in types and such) claim in their __module__ attribute that they come from __builtin__ which is not technically correct since you can't access them from there. The desire to fix this came from allowing for proper introspection. The leading idea is to put these types in __builtin__ properly so that they are no longer lying about where they come from. Contributing threads: - `Classes that claim to be defined in __builtin__ but aren't `__ --------------------------------------------------------- Bringing order to the order of application for decorators --------------------------------------------------------- 1. minor language change Turns out that the order of application for decorators was implemented in the reverse order of what it was supposed to be in 2.4a2 . Luckily James Knight spotted this and let the list know. It has been fixed, though, in CVS and now follows `PEP 318`_ to apply in bottom-up order:: @first @second def blah(): pass is equivalent to:: blah = first(second(blah)) The arguments for this ordering beyond it just making more sense to Guido and others is that people will typically put decorators such as staticmethod and classmethod first. Going with the original order would have led to errors in most situations if people were not expecting to be receiving a class or static method to be passed to the other decorators. There was a short discussion on the order of instantiation for the decorators, but in the end the order chosen was the order listed; first would be first() instantiated followed by second(). Contributing threads: - `Decorator order implemented backwards? `__ ----------------------------------------------------------------------------------- PEP 292 (Simpler String Substitutions) getting gussied up for the Python 2.4a3 ball ----------------------------------------------------------------------------------- 1. minor language change `PEP 292`_'s implementation got fixed up. The names of the class names were changed to Template and SafeTemplate, the whole process was made lazy, and just cleaned up in general (solution is small, simple, and rather cool; all subclassable and works with Unicode to boot). But then questions over the merits of $-based string interpolation popped up. People wondered if going from ``%(blah)s`` to ``${blah}`` was worth it. The answer is "yes". And that is just worst case; when you just want ``$blah`` you get an even bigger win. The other question was over whether the string module should become a package. The original idea was to stick the original string module in as a submodule of the package and the Template code in another module. This would allow easy removal of the 'string' module code that has been deprecated for eons. Barry Warsaw (author of the PEP) asked Guido to make the call on this, but he hasn't had the time yet to get to this. .. _PEP 292: http://www.python.org./peps/pep-0292.html Contributing threads: - `PEP 292 `__ -------------------------------- Multi-line imports get clarified -------------------------------- 1. minor language change Multi-line imports will only accept parentheses around what is being explicitly imported and only if there is more than one item being imported. Trailing commas are also to be accepted. Contributing threads: - `Multi-line import implementation (first part) `__ - `Multi-line import implementation (second part) `__ - `Naming nit `__ ------------------------------------------------ For those of you who need Python to run on Win64 ------------------------------------------------ 3. nuggets of info Nick Bastin asked if anyone has gotten Python 2.3 to work under Win64. Martin v. L?wis said "yes" for Python 2.4, but not for 2.3 . He suggested to Nick that he run vsextcomp_ to generate the targets on the 2.4 VC 7 build files and then move that over to 2.3 . .. _vsextcomp: http://www.sf.net/projects/vsextcomp Contributing threads: - `2.3.4 on Win64? `__ ---------------------------------------------- Sometimes concealing the truth is a good thing ---------------------------------------------- 1. improvement stuff Nick Coghlan discovered that some of the function in the 'commands' module did actually work under Windows and he wanted to make sure it was okay to fix another module to work under Windows and to document the fact. But the whole idea was shot down by both Tim Peters and Guido in order to keep the module simple. Keeping the whole thing UNIX-only is much easier than having an API that is only partly compatible with Windows (and with only certain versions of Windows at that). Guido also said that the module would not even be accepted today since it doesn't add enough functionality. Contributing threads: - `'commands' module on Win32 `__ ---------------------------------------------- atexit module, good; sys.exitfunc, not so good ---------------------------------------------- 1. improvement stuff Raymond Hettinger pointed out that the docs for the atexit module state that sys.exitfunc was to be deprecated. Well, atexit has been in the stdlib since 2.0 so the deprecation is long overdue. Looks like it will get its deprecation finally. Contributing threads: - `Deprecate sys.exitfunc? `__ ---------------------------------------------------------------------------------------------- My Personal Hell: decorators and the people who suggest new syntax for them... next, on Oprah ---------------------------------------------------------------------------------------------- language evolution What led to a record-setting flurry of emails to python-dev was set up when Guido gave the green light to checking in code to implement decorators using the '@' syntax (now known at the pie syntax thanks to its checkin coming very shortly after the OSCON Pie-thon competition and '@' sort of looking like a pie). People didn't like it. People were screaming that there had to be a better syntax than just settling for the least offensive one. Others started to question whether decorators were really needed. Others wanted to extend them even more and what their role truly was. Either way this was all coming a little late. But then Guido decided to make my life difficult by saying that if the community could come up with an agreed-upon alternative syntax to propose to him he would consider ripping out the '@' syntax; decorators have always been experimental and '@' was checked in so people had *something* to play with. This meant everyone and their mother started to propose both new and old syntaxes for decorators. This led to a record amount of email on python-dev (at least compared to what we have archives for; back to April 1999). In order of my own personal sanity I am not going to cover any specific syntax. There are just too many and I actually like the '@' syntax (just *try* using it; it grows on you quickly). Instead this summary will cover any important design considerations for decorators (it should all be in the PEP but so much happened there is no way it all got in there) along with any other important considerations about them. I will discuss anything specific to the '@' syntax since it is the currently winning syntax. With that said, `PEP 318`_ and the PythonDecorators_ wiki page are the de-facto place for info on this whole situation. I am probably going to be more biased than normal in this summary just out of time restraints to get this done by not over-analyzing people's suggestions and just assuming what I summarize here is not covered elsewhere; checking if it is would take too long. First off, going with a syntax just so you could add backward-compatible support was not considered worth it. It's a new feature so there is no need to hobble it at the get-go just so people who don't want to upgrade can still use it. Plus the implementations to make this even possible were playing some tricks with the interpreter and not considered a good thing. Besides you can, always will be able to, still use the way to do it in 2.2 and beyond. Another design point that needed to be taken into consideration was ambiguity. There could not be a question about what is a decorator and what isn't (list-before-def is an example of a syntax that can be ambiguous). Syntactic support that allowed for possible future compiler optimizations was also considered important. The on-going hope is to eventually get a JIT compiler for Python and if the decorators are not placed before the def somehow you make it much harder to optimize since you learn about the decorators after the fact of the function starting to be defined. An argument against '@' was that people thought it got rather unwieldy quickly (and I am sure the new decision that each decorator must be on its own line is not making these objectors happy). But one thing that must be remembered is that chances are most functions will not need more than one decorator if the even need one. Looking through the stdlib sans the test suite you will notice there are not a lot of uses for any of the built-in decorators. Yes, usage will probably grow with syntactic support for decorators, but not exponentially in terms of applying multiple decorators to a single function. Allowing decorators to take arguments is a requirement. Not being able to pass arguments to a decorator at instantiation time would severely cripple their usefulness. Being prefix instead of postfix was considered important. Knowing about what is coming up was something Guido thought is better than finding out about some special tweak to the use of a function based on a decorator listed after the definition line. And in the method body had been completely ruled out. In terms of implementation details, decorators can only be functions directly (and not lambda). This means no ``@a or b`` tricks and such. It also means ``@foo().bar()`` is not allowed. This is all gut feeling from Guido for why the restriction should be there. It could change in the future since it is easier to loosen restrictions that make something more strict. A problem with '@' in terms of portability is that Leo_ and IPython_ both use '@' for special syntax. The authors of both tools seem willing to change their tools (not necessarily overly joyous, though =) . Guido wanted a syntax "that ... [is] easy to remember once explained". It did not need to be miraculously obvious what it did just by looking at the first time. Some people didn't like '@' because they keep wanting to say "at" when they saw it. To that, I give you Tim Peters' fix for this: "Pick the keyword you'd like. Then whenever you see "@", pronounce that word instead ". A single decorator that applied to multiple code blocks is completely out. Guido gave a couple of reasons why, but one that he had mentioned multiple times is indenting the code block again just for the decorator is out. Some people suggested that things be kept simple by just throwing out the entire idea of syntactic support. Could happen if everyone agreed to that, but I wouldn't count on it. A supposed knock against '@' was that it wasn't Pythonic. Well, it is Pythonic if Guido says it is so not really a valid argument. OK, tirade time. If you don't want to listen to me get up on my soapbox, then just skip the rest of this... "In the old days, Guido would Pronounce, and we'd all bite our tongues (although not necessarily each his own). The less time Guido can make for Python, the more important becomes graceful capitulation." Tim said this and it makes me wish for the old days. People had *months* to comment on decorators and no one spoke up until something went into the language. Procrastination is not a virtue when it comes to major language evolution discussions. What was worse was when the emails started repeating themselves (which was pretty much from the get-go when this exploded). Seemed like people decided to start talking without doing some research. Granted the PEP was outdated and the wiki page was not up yet, but this stuff was covered in the Summaries before and you could have just Googled for the previous threads. Personally, if I was Guido, I would have said that the community had their chance to speak up and they just didn't take it. But Guido is a nicer guy than that so people are getting a second chance with this. Personally this came off a great case of the tyranny of the majority in my eyes. There is a reason why Python is a dictatorship. At this point people should be hashing out which syntax alternative they want to present to Guido on comp.lang.python_. No more talking on python-dev, no more syntax proposals. The community should set a goal date (Sept. 1 seems good) and just choose a bloody alternative. Then when Guido makes his choice people accept it or just go to another language. No one had better voice their disappoint once Guido chooses his syntax or I will personally come beat you over with a stick for being a whiner. OK, that's out of my system. I feel better now. .. _PythonDecorators: http://www.python.org/cgi-bin/moinmoin/PythonDecorators .. _Leo: http://leo.sourceforge.net/ .. _IPython: http://ipython.scipy.org/ Contributing threads (sans emails that were warnocked): - `2.4a2, and @decorators `__ - `Plea for simpler decorator syntax, in addition to pie-shaped syntax `__ - `Call for defense of @decorators `__ - `@decorators, the PEP and the "options" out there? `__ - `About pep 318--Intro `__ - `Questions about '@' in pep 318 `__ - `A usability argument for list-after-def `__ - `The impact of '@' on Leo `__ - `Similar syntax `__ - `def fn (args) [dec,dec]: `__ - `pep 318, Decorators for Functions, Methods and Classes `__ - `Density of pie-decorator syntax `__ - `elements of decorator syntax suggestions `__ - `318: Annotation background `__ - `IPython, @, and option E from the wiki `__ - `Decorators: vertical bar syntax `__ - `Suggesting '.' decorators (PEP318) `__ - `Attribute strings? `__ - `request: add keywords for static and class methods only `__ - `@decorator syntax is sugar, but for what exactly? `__ - `Semantics of decorators? `__ - `A decorator syntax not yet mentioned (I think!) `__ - `Another approach to decorators. `__ - `Decorators after 'def' should be reconsidered `__ - `def ... decorate `__ - `Decorator syntax J2 (decorate..def) `__ - `Decorators and docstrings `__ - `block-based decorators and other block issues `__ - `More concerns about decorators `__ From stani_ at hotmail.com Tue Aug 24 11:51:24 2004 From: stani_ at hotmail.com (SM) Date: Tue Aug 24 20:37:03 2004 Subject: SPE 0.5.1.E (Python IDE with wxGlade,pychecker&kiki) Message-ID: <99230dbb.0408240151.7755c570@posting.google.com> This bugfix release works with the new wxPython 2.5.2.7 For more info, see: http://spe.pycs.net From sabry at cs.indiana.edu Tue Aug 24 17:36:19 2004 From: sabry at cs.indiana.edu (Amr Sabry) Date: Tue Aug 24 20:37:04 2004 Subject: ICFP'04 early registration deadline Message-ID: ****************************************************** *** Early registration rates expire 25 August 2004 *** ****************************************************** The 2004 International Conference on Functional Programming (ICFP) Snowbird, Utah September 19-22, 2004 Registration, hotel information, arrangements for shared trips and hotel rooms, conference program (accepted papers, poster session, and affiliated workshops on Erlang, Haskell, and Scheme) at the following web site: http://www.cs.indiana.edu/icfp04/ From dyoo at hkn.eecs.berkeley.edu Tue Aug 24 18:27:05 2004 From: dyoo at hkn.eecs.berkeley.edu (Daniel Yoo) Date: Tue Aug 24 20:37:04 2004 Subject: scanf-1.0 for Python Message-ID: Hi everyone, I've implemented a scanf-like module in pure Python: http://hkn.eecs.berkeley.edu/~dyoo/python/scanf/ If you've ever had the itch to do something like: ### import scanf (cmd, errors, warnings) = ( scanf.sscanf("/usr/sbin/sendmail - 0 errors, 4 warnings", "%s - %d errors, %d warnings")) ### I hope this helps! From aleaxit at yahoo.com Wed Aug 25 16:05:50 2004 From: aleaxit at yahoo.com (Alex Martelli) Date: Fri Aug 27 15:48:14 2004 Subject: Python Cookbook Second Edition call for submissions Message-ID: <1gj30l9.m2q0t1at1d8lN%aleaxit@yahoo.com> Greetings, fellow Pythonistas! We (Alex Martelli, David Ascher and Anna Martelli Ravenscroft) are in the process of selecting recipes for the Second Edition of the Python Cookbook. Please contribute your recipes (code and discussion), along with comments on and ratings of existing recipes, to the cookbook site, http://aspn.activestate.com/ASPN/Cookbook/Python , and do it *now*! The Python Cookbook is a collaborative collection of your contributions to Python lore, with code available for use and review at http://aspn.activestate.com/ASPN/Cookbook/Python . ActiveState and O'Reilly Media provide resources to publish selected recipes from this collection -- selected, edited, and organized into chapters, each of which starts with an essay by an expert in the chapter's topic -- into a book titled (duh!) "Python Cookbook". The First Edition of "Python Cookbook" appeared in 2002, is still in print (selling well), and has met with the kind of sales and review success you all deserved, as a unique book with over 200 recipes by over 100 authors on all sorts of topics relevant to Python versions from 1.5.2 to 2.2. Nevertheless, Python has grown in important ways since then, and deserves an encore: the Second Edition of "Python Cookbook" will appear in 2005 and will focus strictly on Python 2.3 and 2.4. Please contribute to the cookbook site *now* for your submissions to be considered for publication. We especially like recipes that include relevant discussion (not just code), and we're biased in favour of recipes "showing off" specific techniques in code snippets (rather than large, complete programs). Useful comments can also qualify you for the coveted "contributor" status. We're particularly interested in materials based on the new features of Python 2.4 -- Python 2.4 (alpha 2 at the time of this writing) is currently available for download at www.python.org, so, get going: download it, install it, try it out, and submit recipes based on it! As was done for the First Edition, contributors whose recipes and comments we use in the book will receive a complimentary copy of the Second Edition, and a portion of all royalties will go to the non-profit Python Software Foundation. As for the First Edition, recipes to be included in the Second Edition should be licensed under the modified Berkeley license, making them candidates for inclusion in a future Python distribution. Submission deadlines (for possible publication in the Second Edition): Materials based on Python 2.3: Saturday, September 4, 2004 Materials specific to Python 2.4: Saturday, September 25, 2004 Alex From michael at hobbshouse.org Wed Aug 25 18:56:32 2004 From: michael at hobbshouse.org (Michael Hobbs) Date: Fri Aug 27 15:48:15 2004 Subject: ANN: Python + Erlang = Candygram Message-ID: <16999.209.46.8.140.1093452992.squirrel@mail.hobbshouse.org> Announcing the first public release of Candygram: Candygram 1.0 beta 1 Candygram is a Python implementation of Erlang concurrency primitives. Erlang is widely respected for its elegant built-in facilities for concurrent programming. This package attempts to emulate those facilities as closely as possible in Python. With Candygram, developers can send and receive messages between threads using semantics nearly identical to those in the Erlang language. More information about Candygram can be found at http://candygram.sourceforge.net From inigoserna at terra.es Wed Aug 25 22:54:12 2004 From: inigoserna at terra.es (=?ISO-8859-1?Q?I=F1igo?= Serna) Date: Fri Aug 27 15:48:15 2004 Subject: ANN: googlenews.py Message-ID: <1093467252.15882.15.camel@inigo.katxi.org> hi there, while half the world is watching Olympic Games and the other half is discussing about decorators, and as far as my good proposal ("#decorator" :) has been sadly ignored, I've spent last days writing googlenews.py [1], a simple python script to retrieve news from the http://news.google.com service. Supported feeds: es, fr, de, it, nz, au, in, ca, uk, us Can export to: rss2 xml and html files Requirements: - Python 2.3+ - BeautifulSoap (http://www.crummy.com/software/BeautifulSoup) I use it in a hourly cron script, building rss files which I read with liferea : [inigo@inigo inigo]$ cat /etc/cron.hourly/googlenews #!/bin/bash /home/devel/mine/googlenews/googlenews.py --rss-path=/tmp -w -q es /home/devel/mine/googlenews/googlenews.py -cnes --rss-path=/tmp -w -q nz exit 0 [inigo@inigo inigo]$ type "googlenews.py --help" for more info. Hope you like it, I?igo [1] http://inigo.katxi.org/devel/misc/googlenews.py [2] http://liferea.sourceforge.net -- I?igo Serna Katxijasotzaileak -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente Url : http://mail.python.org/pipermail/python-announce-list/attachments/20040825/86daa66f/attachment.pgp From uche.ogbuji at fourthought.com Fri Aug 27 07:44:17 2004 From: uche.ogbuji at fourthought.com (Uche Ogbuji) Date: Fri Aug 27 15:48:16 2004 Subject: ANN: Scimitar 0.6.0 Message-ID: <1093585456.3314.2424.camel@borgia> http://uche.ogbuji.net/tech/4Suite/scimitar Scimitar is an implementation of ISO Schematron that compiles a Schematron schema into a Python validator script, making it a faster and somewhat more flexible approach than the usual XSLT implementations. http://www.ascc.net/xml/resource/schematron/schematron.html Schematron is an XML schema language in which you express a set of rules that the document must meet, rather than expressing a full grammar for the XML vocabulary (which is the more common approach to XML schemata). It is by far the most flexible XML schema language available. Scimitar supports all of Schematron except for abstract patterns. See the TODO file for gaps in Scimitar functionality and convenience, which are being worked on. Scimitar is open source, provided under the 4Suite variant of the Apache license. The compiler program runs standalone on Python 2.2 or more recent, although if you are using an earlier version than 2,3, you must also install Optik 1.4.1 or more recent. In addition to the above requirements the generated validators require 4Suite 1.0a3 or more recent (really only tested with latest 4Suite CVS). -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Meet me at XMLOpen Sept 21-23 2004, Cambridge, UK. http://xmlopen.org Practical (Python) SAX Notes - http://www.xml.com/pub/a/2004/08/11/py-xml.html XML circles the globe - http://www.javareport.com/article.asp?id=9797 Element structures for names and addresses - http://www.ibm.com/developerworks/xml/library/x-elemdes.html Commentary on "Objects. Encapsulation. XML?" - http://www.adtmag.com/article.asp?id=9090 Harold's Effective XML - http://www.ibm.com/developerworks/xml/library/x-think25.html A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/ From edreamleo at charter.net Sat Aug 28 15:45:42 2004 From: edreamleo at charter.net (Edward K. Ream) Date: Mon Aug 30 16:32:10 2004 Subject: ANN: Leo 4.2 beta 3 Message-ID: <10j13903bbfe266@corp.supernews.com> Leo 4.2 Beta 3 is now available at http://sourceforge.net/projects/leo/ This version of Leo is feature complete. Leo's core code has been stable for several months. To do: most plugins work with the new code base, but other plugins need some more work. Late note: the *nix install script will work better with *nix line endings :-) The highlights of Leo 4.2: - @thin trees make Leo much more friendly to cvs. - Leo's data structures have been reorganized to make outline operations significantly faster. All old script still work. - @test and @script nodes convert scripts to unit tests automatically. Converting scripts to unit tests now takes a few seconds! - A faster and more robust spell checker plugin. (requires Python 2.3) - Leo is now much more friendly to using spaces instead of tabs. - The Execute Script command reports erroneous lines more clearly. - The Perfect Import feature guarantee that Leo imports file exactly. - Leo draws large outlines more quickly with less memory used. - Dozens of other improvements. Quote of the month ------------------ Leo is the best IDE that I have had the pleasure to use. I have been using it now for about 2 -- 3 months. It has totally changed not only the way that I program, but also the way that I store and organize all of the information that I need for the job that I do. -- Ian Mulvany What is Leo? ------------ - A programmer's editor, an outlining editor and a flexible browser. - A literate programming tool, compatible with noweb and CWEB. - A data organizer and project manager. Leo provides multiple views of projects within a single outline. - Fully scriptable using Python. Leo saves its files in XML format. - Portable. leo.py is 100% pure Python. - Open Software, distributed under the Python License. Leo requires Python 2.2.1 or above and tcl/tk 8.4 or above. Leo works on Linux, Windows and MacOs X. Links: ------ Leo: http://webpages.charter.net/edreamleo/front.html Home: http://sourceforge.net/projects/leo/ Download: http://sourceforge.net/project/showfiles.php?group_id=3458 CVS: http://sourceforge.net/cvs/?group_id=3458 Wiki: http://leo.hd1.org/ Edward K. Ream August 10, 2004 -------------------------------------------------------------------- Edward K. Ream email: edreamleo@charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html -------------------------------------------------------------------- From wichert at wiggy.net Sat Aug 28 21:09:08 2004 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon Aug 30 16:32:11 2004 Subject: pyrad 0.8 - native python RADIUS implementation Message-ID: <20040828190908.GA16160@wiggy.net> pyrad is an implementation of a RADIUS client and server as described in RFC2865, 2866, and others. It takes care of all the details like building RADIUS packets, sending and receiving them, and en-/decoding responses. (RADIUS is a common protocol used for authentication, authorisation and accounting for remote access (and similar) services). Changes since previous release ------------------------------ * Fix time-handling in the client packet sending code: it would loop forever since the now time was updated at the wrong moment. Fix from Michael Mitchell. * Fix passing of dict parameter when creating reply packets Example ------- Here is an example of doing a authentication request: import pyrad.packet from pyrad.client import Client from pyrad.dictionary import Dictionary srv=Client(server="radius.my.domain", secret="s3cr3t", dict=Dictionary("dicts/dictionary", "dictionary.acc")) req=srv.CreateAuthPacket(code=pyrad.packet.AccessRequest, User_Name="wichert", NAS_Identifier="localhost") req["User-Password"]=req.PwCrypt("password") reply=srv.SendPacket(req) if reply.code==pyrad.packet.AccessAccept: print "access accepted" else: print "access denied" print "Attributes returned by server:" for i in reply.keys(): print "%s: %s" % (i, reply[i]) And an example for a trivial RADIUS server: from pyrad import dictionary, packet, server class FakeServer(server.Server): def _HandleAuthPacket(self, fd, pkt): server.Server._HandleAuthPacket(self, fd, pkt) reply=self.CreateReplyPacket(pkt) reply.code=packet.AccessAccept self.SendReplyPacket(fd, reply) srv=FakeServer(dict=dictionary.Dictionary("dictionary")) srv.hosts["127.0.0.1"]=server.RemoteHost("127.0.0.1", "s3cr3t", "localhost") srv.BindToAddress("") srv.Run() Requirements ------------ pyrad requires Python 2.2 or later. Author, copyright, availability ------------------------------- pyrad was written by Wichert Akkerman The current version and documentation can be found at its homepage: http://www.wiggy.net/code/pyrad/ Copyright 2002-2004 Wichert Akkerman. All rights reserved. pyrad is distributed under the BSD license. Please see the source archive for the full license text. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From mark at pycs.org Sun Aug 29 05:22:12 2004 From: mark at pycs.org (Mark Hahn) Date: Mon Aug 30 16:32:12 2004 Subject: New Python-like language development starting Message-ID: <004b01c48d77$653abf30$0d01a8c0@MarkVaio> This is an announcement of the beginning of development of a new Python-like language called PyCs (pronounced "pie-cees"). Like IronPython, PyCs will be Python on .Net but it will have more advanced features and probably have higher performance due to a Psyco-like implementation technique. See http://pycs.org. PyCs is a fusion of Python and C#. It is the first Python-like dynamic language with all the capabilities of C# including the capabilities of the research language C-Omega (http://research.microsoft.com/Comega/) including the X# language features (http://www.cl.cam.ac.uk/%7Egmb/Papers/vanilla-xml2003.html) that embed XML/SQL support directly in the language. At the same time PyCs keeps all the advantages of the Python language and the Python way. PyCs will not be source compatible with either C# or Python but code could be ported from either one easily. PyCs is being developed by Mark Hahn who developed Prothon and PyCs grew out of the initial efforts to port Prothon to .Net. For an explanation of why the Prothon port to .Net turned into a whole new language, see http://prothon.org/pycsnews.htm. PyCs is just now starting development and will be developed using the same XP-like language design process used to develop Prothon. This process will use the PyCs mailing list to design the language where Mark acts as moderator and implements the language in real-time as the ideas are worked out. He will be working on PyCs full-time and drive the development just as he did with Prothon. Please join the PyCs team. The only effort involved is particpating in a low-traffic, high-content, mailing list. You will be able to influence the design of the latest and greatest dynamic language. -- Mark Hahn, http://pycs.org From darcy at PyGreSQL.org Mon Aug 30 02:18:08 2004 From: darcy at PyGreSQL.org (D'Arcy J.M. Cain) Date: Mon Aug 30 16:32:12 2004 Subject: Release of PyGreSQL 3.5 Message-ID: <20040829201808.0b3dbdc8.darcy@PyGreSQL.org> Announce: Release of PyGreSQL version 3.5 ========================================= PyGreSQL v3.5 has been released. It is available at: ftp://ftp.druid.net/pub/distrib/PyGreSQL-3.5.tgz. If you are running NetBSD, look in the packages directory under databases. There is also a package in the FreeBSD ports collection. >From March 1 2001 the PyGreSQL development has moved into the PostgreSQL development tree. Starting with the last release it has been moved back to a separate project. We are also now joined by the PoPy team and future versions will have a merged version of the two systems. PostgreSQL is a database system derived from Postgres4.2. It conforms to (most of) ANSI SQL and offers many interesting capabilities (C dynamic linking for functions or type definition, etc.). This package is copyright by the Regents of the University of California, and is freely distributable. Python is an interpreted programming language. It is object oriented, simple to use (light syntax, simple and straightforward statements), and has many extensions for building GUIs, interfacing with WWW, etc. An intelligent web browser (HotJava like) is currently under development (November 1995), and this should open programmers many doors. Python is copyrighted by Stichting S Mathematisch Centrum, Amsterdam, The Netherlands, and is freely distributable. PyGreSQL is a python module that interfaces to a PostgreSQL database. It embeds the PostgreSQL query library to allow easy use of the powerful PostgreSQL features from a Python script. This release fixes a few bugs, adds a few minor features and makes a few speedups in the code. It works with Python version 2.3 and PostgreSQL version 7.3 and up. See the other changes below or in the Changelog file. PyGreSQL 2.0 was developed and tested on a NetBSD 1.3_BETA system. It is based on the PyGres95 code written by Pascal Andre, andre@chimay.via.ecp.fr. I changed the version to 2.0 and updated the code for Python 1.5 and PostgreSQL 6.2.1. While I was at it I upgraded the code to use full ANSI style prototypes and changed the order of arguments to connect. Later versions are fixes and enhancements to that. The latest version of PyGreSQL works with Python 1.5.2 and PostgreSQL 7.0.x Important changes from PyGreSQL 3.4 to PyGreSQL 3.5 - Add interval to list of data types - fix up method wrapping especially close() - retry pkeys once if table missing in case it was just added - wrap query method separately to handle debug better - use isinstance instead of type - fix free/PQfreemem issue - finally Important changes from PyGreSQL 3.3 to PyGreSQL 3.4 - Moved back out of PostgreSQL tree - Allow for larger integer returns - Return proper strings for true and false - Cleanup convenience method creation - Enhance debugging method - Add reopen method - Allow programs to preload field names for speedup - Move OID handling so that it returns long instead of int - Miscellaneous cleanups and formatting Important changes from PyGreSQL 3.2 to PyGreSQL 3.3 - Added NUMERICOID to list of returned types. This fixes a bug when returning aggregates in the latest version of PostgreSQL. Important changes from PyGreSQL 3.1 to PyGreSQL 3.2 Note that there are very few changes to PostgreSQL between 3.1 and 3.2. The main reason for the release is the move into the PostgreSQL development tree. Even the WIN32 changes are pretty minor. - Add WIN32 support (gerhard@bigfoot.de) - Fix some DB-API quoting problems (niall.smart@ebeon.com) - Moved development into PostgreSQL development tree. Important changes from PyGreSQL 3.0 to PyGreSQL 3.1 - Fix some quoting functions. In particular handle NULLs better. - Use a method to add primary key information rather than direct manipulation of the class structures. - Break decimal out in _quote (in pg.py) and treat it as float. - Treat timestamp like date for quoting purposes. - Remove a redundant SELECT from the get method speeding it, and insert since it calls get, up a little. - Add test for BOOL type in typecast method to pgdbTypeCache class. (tv@beamnet.de) - Fix pgdb.py to send port as integer to lower level function (dildog@l0pht.com) - Change pg.py to speed up some operations - Allow updates on tables with no primary keys. Important changes from PyGreSQL 2.4 to PyGreSQL 3.0: - Remove strlen() call from pglarge_write() and get size from object. (Richard@Bouska.cz) - Add a little more error checking to the quote function in the wrapper - Add extra checking in _quote function - Wrap query in pg.py for debugging - Add DB-API 2.0 support to pgmodule.c (andre@via.ecp.fr) - Add DB-API 2.0 wrapper pgdb.py (andre@via.ecp.fr) - Correct keyword clash (temp) in tutorial - Clean up layout of tutorial - Return NULL values as None (rlawrence@lastfoot.com) (WARNING: This will cause backwards compatibility issues.) - Change None to NULL in insert and update - Change hash-bang lines to use /usr/bin/env - Clearing date should be blank (NULL) not TODAY - Quote backslashes in strings in _quote (brian@CSUA.Berkeley.EDU) - Expanded and clarified build instructions (tbryan@starship.python.net) - Make code thread safe (Jerome.Alet@unice.fr) - Add README.distutils (mwa@gate.net & jeremy@cnri.reston.va.us) - Many fixes and increased DB-API compliance by chifungfan@yahoo.com, tony@printra.net, jeremy@alum.mit.edu and others to get the final version ready to release. Important changes from PyGreSQL 2.3 to PyGreSQL 2.4: - Insert returns None if the user doesn't have select permissions on the table. It can (and does) happen that one has insert but not select permissions on a table. - Added ntuples() method to query object (brit@druid.net) - Corrected a bug related to getresult() and the money type - Corrected a bug related to negative money amounts - Allow update based on primary key if munged oid not available and table has a primary key - Add many __doc__ strings. (andre@via.ecp.fr) - Get method works with views if key specified Important changes from PyGreSQL 2.2 to PyGreSQL 2.3: - connect.host returns "localhost" when connected to Unix socket (torppa@tuhnu.cutery.fi) - Use PyArg_ParseTupleAndKeywords in connect() (torppa@tuhnu.cutery.fi) - fixes and cleanups (torppa@tuhnu.cutery.fi) - Fixed memory leak in dictresult() (terekhov@emc.com) - Deprecated pgext.py - functionality now in pg.py - More cleanups to the tutorial - Added fileno() method - terekhov@emc.com (Mikhail Terekhov) - added money type to quoting function - Compiles cleanly with more warnings turned on - Returns PostgreSQL error message on error - Init accepts keywords (Jarkko Torppa) - Convenience functions can be overridden (Jarkko Torppa) - added close() method Important changes from PyGreSQL 2.1 to PyGreSQL 2.2: - Added user and password support thanks to Ng Pheng Siong - Insert queries return the inserted oid - Add new pg wrapper (C module renamed to _pg) - Wrapped database connection in a class. - Cleaned up some of the tutorial. (More work needed.) - Added version and __version__. Thanks to thilo@eevolute.com for the suggestion. Important changes from PyGreSQL 2.0 to PyGreSQL 2.1: - return fields as proper Python objects for field type - Cleaned up pgext.py - Added dictresult method Important changes from Pygres95 1.0b to PyGreSQL 2.0: - Updated code for PostgreSQL 6.2.1 and Python 1.5. - Reformatted code and converted to ANSI . - Changed name to PyGreSQL (from PyGres95.) - Changed order of arguments to connect function. - Created new type pgqueryobject and moved certain methods to it. - Added a print function for pgqueryobject - Various code changes - mostly stylistic. For more information about each package, please have a look to their web pages: - Python : http://www.python.org/ - PostgreSQL : http://www.PostgreSQL.org/ - PyGreSQL : http://www.PyGreSQL.org/ -- D'Arcy J.M. Cain PyGreSQL Development Group http://www.PyGreSQL.org From dm-info at 163.com Mon Aug 30 10:11:19 2004 From: dm-info at 163.com (tocer) Date: Mon Aug 30 16:32:13 2004 Subject: ANN:pyCallTips 0.5, a script make Vim support calltips for Python Message-ID: <6aa4af73.0408300011.149a15e4@posting.google.com> If some pythoner complain that Vim don't support calltips of python, now I implement it. Try it and wish you enjoy it. http://vim.sourceforge.net/scripts/script.php?script_id=1074 Intro: This script simualate code calltips in a new bottow window of Vim. In fact, it display python help doc strings of word under the cursor by scanning the imported modules in the current file. 0.5 enhance 0.3 and fix many bugs. From robin at alldunn.com Mon Aug 30 20:11:27 2004 From: robin at alldunn.com (Robin Dunn) Date: Mon Aug 30 21:01:59 2004 Subject: ANNOUNCE: wxPython 2.5.2.8 Message-ID: <41336DCF.60503@alldunn.com> Announcing ---------- I'm pleased to announce the 2.5.2.8 release of wxPython, now available for download at http://wxpython.org/download.php or https://sourceforge.net/project/showfiles.php?group_id=10718&package_id=10559&release_id=263903 What is wxPython? ----------------- wxPython is a GUI toolkit for the Python programming language. It allows Python programmers to create programs with a robust, highly functional graphical user interface, simply and easily. It is implemented as a Python extension module that wraps the popular wxWidgets cross platform GUI library, which is written in C++. wxPython is a cross-platform toolkit. This means that the same program will usually run on multiple platforms without modifications. Currently supported platforms are 32-bit Microsoft Windows, most Linux or other Unix-like systems using GTK or GTK2, and Apple Macintosh OS X. Changes in 2.5.2.8 ------------------ This is predominantly a bug-fix release. Changes include: * Fixed fatal error due to improper wrapping of wx.FSFile. * Fixed return type of EditableListBox.GetListCtrl * Give generic tree and list controls a DoGetBestSize so they play nicer with sizers when there is no minimal size. * Some tweaks in the demo and samples to correct layout, some flicker problems, and namespace use. * Add wx.Image.ConvertAlphaToMask * Minor corrections in wx.lib.dialogs * wx.FileHistory constructor now accepts the documented 2nd parameter. * Corrections for exceptions in the new ogl * Fixed XRCed to not use reparenting of windows to implement caching of property panels, since Reparent on wxMac is not implemented. * Add support for wxTAB_TRAVERSAL to the XRC handler for wxScrolledWindow. * Add support for all wxListBox styles to the XRC handler for wxCheckListBox. * Fix for wx.Listbook.DeleteAllPages to really delete everything. * wxGTK2 now supports alpha blended bitmap drawing * Made wx.grid.Grid play nicer with sizers. * etc. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! From jbellis at gmail.com Tue Aug 31 17:07:45 2004 From: jbellis at gmail.com (Jonathan Ellis) Date: Wed Sep 1 01:35:40 2004 Subject: RSS feed for python.org Jobs.html Message-ID: I've written a script to provide an RSS feed for jobs listed at http://www.python.org/Jobs.html. Point your rss reader to http://www.carnageblender.com/public/ss/pythonjobs.tcl to get the feed, or view the screenscraping source at http://www.carnageblender.com/public/ss/pythonjobs.py. Jonathan Ellis From python-url at phaseit.net Tue Aug 31 21:58:16 2004 From: python-url at phaseit.net (Peter Otten) Date: Wed Sep 1 01:35:41 2004 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Aug 31) Message-ID: QOTW: "Python is clearly on a huge evolutionary surge and conservative views on the matter are definitely not winning out right now. And the usual argument (submit a patch!) doesn't really work when those who want to avoid many changes try it... I've been *not* submitting a patch on lots of changes to Python, but somehow it's never been accepted. ;-)" Peter Hansen "I've never seen a more complicated, verbose pile of hogwash than the 'deliverd by mailman' mailing list program." Carol Carrot, perhaps innocent of experience with Majordomo and Sendmail Michelle Levesque's PyWebOff annotates the Python-savvy Web frameworks. PEP 333 offers to rationalize a piece of them. http://pyre.third-bit.com/pyweb/index.html http://groups.google.com/groups?th=7f19fe19b40c1be0 How do generator expressions and list comprehensions compare? Experts explain why the former are *better*--OK, better in several, although not all, ways http://groups.google.com/groups?frame=left&th=1d4aca073edaaa2f Jim Hugunin domesticates Python for the Microsoft weltanschaung. http://blogs.msdn.com/hugunin/ http://www.eweek.com/article2/0,1759,1636906,00.asp How does Python regard file systems? It's a timely topic, with pyfmf its most concrete expression. http://groups.google.com/groups?frame=left&th=c379db570ef96c43 http://sourceforge.net/projects/pyfmf http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html High-profile Pythoneers Michael Sparks and Alex Martelli demonstrate interests beyond the perfection of the One True Language: petabyte-scale archiving, and marriage. http://www.pcw.co.uk/news/1157046 http://www.aleax.it/mar.html http://bonanna.multiply.com/photos/album/1 Uche Ogbuji reveals his habits for keeping current with Pythonia. http://www.oreillynet.com/pub/wlg/5490 ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Brett Cannon continues the marvelous tradition established by Andrew Kuchling and Michael Hudson of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ The Python Business Forum "further[s] the interests of companies that base their business on ... Python." http://www.python-in-business.org Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor@pythonjournal.com and editor@pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python Suggestions/corrections for next week's posting are always welcome. E-mail to should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project. From Fernando.Perez at colorado.edu Tue Aug 31 23:21:15 2004 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed Sep 1 01:35:41 2004 Subject: ANN: IPython 0.6.3 is out, with matplotlib support. Message-ID: <4134EBCB.2010102@colorado.edu> Announcing an update to IPython, an enhanced interactive Python shell. As always, a big Thank You goes to Enthought and the SciPy crowd for hosting ipython and all its attending support services (bug tracker, mailing lists, website and downloads, etc). * WHAT is IPython? IPython tries to: 1. Provide an interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. Serve as an embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. Offer a flexible framework which can be used as the base environment for other systems with Python as the underlying language. In particular, it provides a profile (pysh) which allows its usage as a quasi system shell, with python syntax. * WHERE to find it: http://ipython.scipy.org * Some highlights of this release (details in the changelog): 1. Matplotlib support The major new feature this time is integrated support for matplotlib (http://matplotlib.sourceforge.net). Thanks to the help of John Hunter (matplotlib's author) and others, IPython now has a new option -pylab. With this flag, it loads and configures matplotlib for interactive use, automatically adapting thread handling to whatever backend is configured in your .matplotlibrc file. This means that you can use Tk, GTK, or WX and IPython automatically handles threading for you so that the matplotlib figure windows do NOT block the shell. The matplotlib features have been tested and work fairly well under Linux, though it's quite possible that bugs remain (threading code is particularly tricky to debug). However, under Mac OSX and Windows we have run into difficulties which we don't know how to solve yet. It appears that for these platforms, at this point only the Tk/TkAgg backends work well. Anyone who works on these systems and knows about threads is welcome to help; the place to look is towards the end of Ipython/Shell.py, where all the thread-handling classes reside. I'd like to thank John for all the time he spent helping me with this. I think for those interested in scientific computing, the combination of matplotlib and ipython makes for a very interesting environment. Please note that this requires matplotlib version 0.62.4 or newer, as John and I coordinated the development of these features, and it required changes to both ipython and matplotlib. 2. GTK & WXPython threading There is also experimental, but disabled by default, support for generic (i.e. not specific to matplotlib) GTK and WX threading. Ideally, IPython should allow you to run arbitrary GTK or WX programs without blocking, and new -gthread/-wthread options were introduced for this purpose. However, this code is not working correctly and my threading knowledge is very limited. If anyone is interested in this kind of functionality, and can help with debugging, simply modify the start() function at the end of IPython/Shell.py to re-enable those options (they are commented out). At that point the threading code will become active again. Any fixes for this will be most welcome. 3. As usual, a number of fixes for recently reported bugs are also included. Enjoy, and please report any problems. Best, Fernando Perez.