Tel +33 (0)1 42 23 67 45
9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88
From mark.m.mcmahon at gmail.com Thu Apr 20 01:52:46 2006
From: mark.m.mcmahon at gmail.com (Mark Mc Mahon)
Date: Wed, 19 Apr 2006 19:52:46 -0400
Subject: ANN: pywinauto 0.3.3 released - bug fixes, added methods,
removed deprecated methods
Message-ID: <71b6302c0604191652g2ac26159wb5a8eab20431f1c6@mail.gmail.com>
Hi,
0.3.3 release of pywinauto is now available.
pywinauto is a set of open-source (LGPL) modules for using Python as a GUI
automation 'driver' for Windows NT based Operating Systems (NT/W2K/XP).
SourceForge project page:
http://sourceforge.net/projects/pywinauto
Download from SourceForge
http://sourceforge.net/project/showfiles.php?group_id=157379
Here is the list of changes from 0.3.2:
0.3.3 Added some methods, and fixed some small bugs
------------------------------------------------------------------
19-Apr-2006
* Added a wait for the control to be active and configurable
sleeps after 'modifying' actions (e.g. Select, Deselect, etc)
* Fixed Timings.Slow() and Timings.Fast() - they could in certain
circumstances do the opposite! If you had already set a timing
slower or faster then they would set it then they would blindly
ignore that and set their own times. I added functionality that
they will take either the slowest or fastest of the new/current
setting rather then blindly setting to the new value.
* Fixed some hidden bugs with HwndWrapper.CloseClick()
* Fixed a bug in setup.py that would raise an error when no
argument was specified
* Added an argument to HwndWrapper.SendMessageTimeout so that
the wait options could be passed in.
* Added HwndWrapper.Close(), Maximize(), Minimize(), Restore()
and GetShowState().
* Commented out all deprecated methods (will be removed completely
in some future release).
* Added Application.kill_() method - which closes all windows and
kills the application. If the application is asking if you want
to save your changes - you will not be able to click yes or no
and the application will be killed anyway!.
If you want to follow this project then please sign up to the mailing list:
https://lists.sourceforge.net/mailman/listinfo/pywinauto-users
Thanks
Mark
--------------------------------------------
Mark Mc Mahon
Manchester, NH 03110, USA
pywinauto 0.3.3
Simple Windows GUI automation with Python. (19-Apr-06)
From gward-1337f07a94b43060ff5c1ea922ed93d6 at python.net Thu Apr 20 03:46:20 2006
From: gward-1337f07a94b43060ff5c1ea922ed93d6 at python.net (Greg Ward)
Date: Wed, 19 Apr 2006 21:46:20 -0400
Subject: ANNOUNCE: Optik 1.5.1
Message-ID: <20060420014620.GA9343@cthulhu.gerg.ca>
Optik 1.5.1 is now available, just 16 months after I first planned to
release it (sigh).
(Optik is a command-line parsing library for Python, also known as
optparse in the standard library; see http://optik.sourceforge.net/ for
blurbs, docs, downloads, etc.)
Changes since 1.5:
* Fix so the 'merge' script works again (bugs spotted, and mostly
fixed, by Andrea 'fwyzard' Bocci).
* SF bug #1145594: add 'destroy()' method to OptionParser so
applications can explicitly break reference cycles, making life
easier for Python's garbage collector.
* SF feature #988126: add 'epilog' attribute to OptionParser
(and constructor arg): paragraph of text to print after the
main option help.
* Corrected French translation (po/optik/fr.po) (Laurent Laporte).
* Beefed up reference guide.
* Backported to Python 2.0/2.1 (Giovanni Bajo).
Greg
--
Greg Ward http://www.gerg.ca/
"... but in the town it was well known that when they got home their fat and
psychopathic wives would thrash them to within inches of their lives ..."
From nnorwitz at gmail.com Thu Apr 20 09:32:56 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 20 Apr 2006 00:32:56 -0700
Subject: Python Software Foundation seeks mentors and students for Google
Summer of Code
Message-ID:
This spring and summer, Google will again provide stipends
for students (18+, undergraduate thru PhD programs) to write
new open-source code.
The Python Software Foundation (PSF)
http://www.python.org/psf/
will again act as a sponsoring organization in Google's Summer of Code,
matching mentors and projects benefiting Python and Python users.
Projects can include work on the core Python language, programmer
utilities, libraries, packages, frameworks related to Python, or
other Python implementations like Jython, PyPy, or IronPython.
Please add your project ideas to the existing set at
http://wiki.python.org/moin/SummerOfCode
Mentoring instructions are also on this page. The deadline is soon,
so please sign up as a mentor early. If you are a student
considering a project, you should start deciding now. Feel free
to ask questions on python-dev at python.org
The main page for the Summer of Code is
http://code.google.com/summerofcode.html
At the bottom are links to StudentFAQ, MentorFAQ, and TermsOfService. The
first two have the timeline. Note that student applications are due
between May 1, 17:00 PST and May 8, 17:00 PST.
People interested in mentoring a student though PSF are encouraged to
contact me, Neal Norwitz at nnorwitz at gmail.com. People unknown to Guido
or myself should find a couple of people known within the Python community
who are willing to act as references.
Feel free to contact me if you have any questions. I look forward to meeting
many new mentors and students. Let's improve Python!
Cheers,
n
From sylvain.thenault at logilab.fr Thu Apr 20 10:06:59 2006
From: sylvain.thenault at logilab.fr (Sylvain =?iso-8859-1?Q?Th=E9nault?=)
Date: Thu, 20 Apr 2006 10:06:59 +0200
Subject: [ANN] PyLint 0.11 / astng 0.16
Message-ID: <20060420080659.GF4037@logilab.fr>
Hi there!
I'm please to announce new releases of pylint (0.11) and its underlying
library astng (0.16). Those releases should fix a number of crashes and false
positive and provide a few new options/features, the most notable one being
the ability to enable/disable messages at block level in the code (I'll post
an example of this new feature on the python-projects mailing-list).
Thanks to every people helping pylint by their feedback and bug reports, and
special thanks to Benjamin Niemann for his message control patch...
To get the new releases of more information :
http://www.logilab.org/projects/pylint/
http://www.logilab.org/projects/astng/
Enjoy !
--
Sylvain Th?nault LOGILAB, Paris (France).
http://www.logilab.com http://www.logilab.fr http://www.logilab.org
From aahz at pythoncraft.com Thu Apr 20 23:46:25 2006
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 20 Apr 2006 14:46:25 -0700
Subject: SPECIAL: BayPIGgies: April 26, 7:30pm (Google)
Message-ID: <20060420214625.GA9590@panix.com>
NOTE: Special date of WEDNESDAY April 26 at Google, usual time of 7:30pm
Special meeting! One of the lead developers of Django is in town! Jacob
Kaplan-Moss will be talking about Django at Google. More details as they
get finalized -- but save the date! (No, it's not on the website yet...)
This does not change the usual May meeting on May 11 at Google; stay
tuned for an announcement of that.
BayPIGgies meetings alternate between IronPort (San Bruno, California)
and Google (Mountain View, California). For more information and
directions, see http://baypiggies.net/
Before the meeting, we sometimes meet at 6pm for dinner. Discussion of
dinner plans is handled on the BayPIGgies mailing list.
Advance notice: We have a speakers for May and June. We are currently
setting up the schedule for the rest of the year. Please e-mail
baypiggies at python.org if you want to suggest an agenda (or volunteer to
give a presentation).
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
"Argue for your limitations, and sure enough they're yours." --Richard Bach
From greg at cosc.canterbury.ac.nz Fri Apr 21 09:56:02 2006
From: greg at cosc.canterbury.ac.nz (greg)
Date: Fri, 21 Apr 2006 19:56:02 +1200
Subject: ANN: Pyrex 0.9.4.1
Message-ID: <4arhgaFuhgj2U1@individual.net>
Pyrex 0.9.4.1 is now available:
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
This is a very minor update to correct a tab/space
problem in the distutils extension.
What is Pyrex?
--------------
Pyrex is a language for writing Python extension modules.
It lets you freely mix operations on Python and C data, with
all Python reference counting and error checking handled
automatically.
--
Greg
From edreamleo at charter.net Fri Apr 21 14:58:01 2006
From: edreamleo at charter.net (Edward K. Ream)
Date: Fri, 21 Apr 2006 07:58:01 -0500
Subject: ANN: Leo 4.4 b4 released
Message-ID:
Leo 4.4 beta 4 is now available at:
http://sourceforge.net/project/showfiles.php?group_id=3458&package_id=29106
This version fixes a long-standing MacOS bug. It is likely to be the last
beta release before 4.4 rc1. This release also adds several new commands
and contains a script for updating leoSettings.leo.
Warning: The previous beta was not widely distributed. Please do some
testing in your environment before recommending this version of Leo to
others, (such as your students).
Leo is a text editor, data organizer, project manager and much more. See:
http://webpages.charter.net/edreamleo/intro.html
The highlights of Leo 4.4:
--------------------------
- An Emacs-like mini-buffer: you can now execute any command by typing its
long name, with tab completion.
- Many new commands, including cursor and screen movement, basic character,
word and paragraph manipulation, and commands to manipulate buffers, the
kill ring, regions and rectangles. You can use Leo without using a mouse.
- Flexible key bindings and input modes. You can emulate the operation of
Emacs, Vim, or any other editor.
- A tabbed log pane. The Find and Spell Check commands now use tabs instead
of dialogs, making those commands much easier to use. Plugins or scripts can
easily create new tabs. The Completion tab shows possible typing
completions.
- Autocompletion and calltips.
- Dozens of other new features and bug fixes since Leo 4.3.3.
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
Quotes: http://webpages.charter.net/edreamleo/testimonials.html
Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo at charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
From aahz at pythoncraft.com Fri Apr 21 22:59:08 2006
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 21 Apr 2006 13:59:08 -0700
Subject: www.python.org problems
Message-ID: <20060421205908.GA11853@panix.com>
Before people start sending a flood of e-mail to webmaster, we already
know that www.python.org is having problems. Please be patient.
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
"Argue for your limitations, and sure enough they're yours." --Richard Bach
From lcrees at gmail.com Sun Apr 23 08:51:19 2006
From: lcrees at gmail.com (L. C. Rees)
Date: 22 Apr 2006 23:51:19 -0700
Subject: webstring 0.2 released
Message-ID: <1145775079.149147.319680@v46g2000cwv.googlegroups.com>
This is the second public release of webstring.
Improvements in this version include speed enhancements and the ability
to mark groups of fields inside an XML/HTML document with an XML/HTML
attribute (by default "class") so they can be manipulated in a single
operation.
webstring is a template system that lets Python programmers manipulate
XML and HTML documents using standard Python sequence and string
operators. It is designed for those whose preferred web template
languages are Python and HTML. webstring's design is inspired by PyMeld
but with a stricter Python feel. Like PyMeld, webstring separates the
view (the XML/HTML document) from the controller (Python). It uses
XML/HTML attributes (by default "id") to mark which tags in a document
are fields where content can be inserted or substituted. webstring
flattens a document into a Python object hierarchy, exposing only parts
of the document you need to manipulate.
webstring is a wrapper for Fredrik Lundh's cElementTree package, so
both cElementTree and elementtree are required. It also requires
Fredrik Lundh's elementtidy package for trying hack through odd HTML.
These packages are available for download at:
http://effbot.org/downloads/
webstring is currently only known to work with Python 2.4.
webstring documentation can be found at:
http://psilib.sourceforge.net/webstring.html
Future planned enhancements include making webstring capable of using
lxml as an optional backend.
The file is available for download from:
http://prdownloads.sourceforge.net/psilib/webstring.py?download
From levub137 at wi.rr.com Sun Apr 23 14:45:38 2006
From: levub137 at wi.rr.com (Raymond L. Buvel)
Date: Sun, 23 Apr 2006 07:45:38 -0500
Subject: [ANN] crcmod-1.3 CRC Generator
Message-ID: <444B76F2.1070103@wi.rr.com>
Crcmod is a Python package for creating functions computing the Cyclic
Redundancy Check (CRC). Any generating polynomial producing 8, 16, 32,
or 64 bit CRCs is allowed. Generated functions can be used in Python or
C/C++ source code can be generated.
Home page: http://crcmod.sourceforge.net/
Changes in 1.3
* Make compatible with Python 2.5 on 64-bit platforms.
* Improve the install procedure.
From cito at online.de Sun Apr 23 23:07:23 2006
From: cito at online.de (Christoph Zwerschke)
Date: Sun, 23 Apr 2006 23:07:23 +0200
Subject: ANN: Webware 0.9.1 released
Message-ID:
Webware 0.9.1 has been released.
This release of Webware for Python includes a few fixes and improvements
of the WebKit, MiddleKit and KidKit components.
Webware for Python is a suite of Python packages and tools for
developing object-oriented, web-based applications. The suite uses well
known design patterns and includes a fast Application Server, Servlets,
Python Server Pages (PSP), Object-Relational Mapping, Task Scheduling,
Session Management, and many other features. Webware is very modular and
easily extended.
Webware for Python is well proven and platform-independent. It is
compatible with multiple web servers, database servers and operating
systems.
Check out the Webware for Python home page at http://www.w4py.org
From cochrane at avon.esscc.uq.edu.au Mon Apr 24 18:11:42 2006
From: cochrane at avon.esscc.uq.edu.au (cochrane at avon.esscc.uq.edu.au)
Date: 24 Apr 2006 16:11:42 GMT
Subject: ANN: PyScript 0.6.0 released
Message-ID:
Overview:
PyScript is a python module for producing high quality postscript
graphics. Rather than use a GUI to draw a picture, the picture is
programmed using python and the PyScript objects.
Some of the key features are:
* All scripting is done in python, which is a high level, easy to
learn, well developed scripting language.
* All the objects can be translated, scaled, rotated, ... in fact
any affine transformation.
* Plain text is automatically kerned.
* You can place arbitrary LaTeX expressions on your figures.
* You can create your own figure objects, and develop a library of
figure primitives.
* Output is publication quality.
License:
Released under the GPL
Changes:
The major change in this release is a complete rewrite of the Talk and
Poster classes of the presentation library. There have also been
many bug fixes and minor other improvements. For details see the
PyScript web page:
pyscript.sourceforge.net.
Getting the software:
One can download the latest version (0.6) from:
PyScript
Requirements:
* Python 2.2 and above
* An up-to-date LaTeX distribution
Authors:
* Alexei Gilchrist
* Paul Cochrane
If you use this software, have any suggestions, or bug reports, please let
us know!
--
paultcochrane at users.sourceforge.net
From fabiofz at gmail.com Mon Apr 24 18:58:55 2006
From: fabiofz at gmail.com (Fabio Zadrozny)
Date: Mon, 24 Apr 2006 13:58:55 -0300
Subject: Pydev and Pydev Extensions 1.0.6 release
Message-ID:
Hi All,
Pydev and Pydev Extensions 1.0.6 have been released
Check http://www.fabioz.com/pydev for details on Pydev Extensions
and http://pydev.sf.net for details on Pydev
Release Highlights in Pydev Extensions:
-----------------------------------------------------------------
- New Feature: Show hierarchy (F4) -- Still in a beta state (currently only
looks for subclasses on the same project).
- Analysis happens in a Thread, so, you should now always have the latest
parse without any halts (this happened only when the option was set to
analyze only on save).
- Class variable marked as error when self ommitted
- when an undefined import is found within a try..except ImportError, it
will not be reported.
- Allow changing the keybinding for activating the Interactive Console
(Ctrl+Enter)
- Added a simple text-search that looks for in all .py and .pyw files (will
be improved in the future to make a real python-like search).
- The keywords that match the 'simple' keywords completion do not show up.
Release Highlights in Pydev:
----------------------------------------------
- Assign variables to attributes (Ctrl+2+a): Contributed by Joel Hedlund
(this is the first contribution using the new jython scripting engine).
- 3 minor 'quirks' were fixed in the indentation engine
- The debugger had some changes (so, if you had halts with it, please try it
again).
- Allow changing the keybinding for activating the Find next problem
(Ctrl+.)
- The debugger step-return had its behaviour changed.
- Additional scripts location added to pythonpath in the jython scripting
engine
- Transversal of nested references improved
- Fixed problems with compiled modules when they had 'nested' module
structures (e.g.: wx.glcanvas)
What is PyDev?
---------------------------
PyDev is a plugin that enables users to use Eclipse for Python and Jython
development -- making Eclipse a first class Python IDE -- It comes with many
goodies such as code completion, syntax highlighting, syntax analysis,
refactor, debug and many others.
Cheers,
--
Fabio Zadrozny
------------------------------------------------------
Software Developer
ESSS - Engineering Simulation and Scientific Software
http://www.esss.com.br
Pydev Extensions
http://www.fabioz.com/pydev
Pydev - Python Development Enviroment for Eclipse
http://pydev.sf.net
http://pydev.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-announce-list/attachments/20060424/f73282fd/attachment.htm
From jdahlin at async.com.br Tue Apr 25 19:34:48 2006
From: jdahlin at async.com.br (Johan Dahlin)
Date: Tue, 25 Apr 2006 14:34:48 -0300
Subject: ANNOUNCE: kiwi 1.9.8
Message-ID: <444E5DB8.8000706@async.com.br>
New in this released is API documentation which is generated using
epydoc[3]. It's still being written but at this point I feel that
it's good enough to be a very useful resource to help understand
kiwi. Kiwi is a PyGTK framework for building graphical applications loosely
based on MVC Model-View-Controller (MVC) and Allen Holub's Visual proxy
[1]. Think of Kiwi as a high-level, object-oriented layer built on
PyGTK.
Its design is based on real-world experience using PyGTK to develop
large desktop applications, which use many concepts common to most
graphical applications: multiple windows and dialogs, forms, data
persistence, lists and high-level classes that support domain objects
directly.
Download
========
Grab the latest sources from:
http://www.async.com.br/projects/kiwi/download/kiwi-1.9.8.tar.gz
What's new since 1.9.7?
=======================
- distutils.setup() replacement
- date tests
- FileChooser & FileChooserButton
- Rename all proxy widgets to start with Proxy
- Win32 installation fixes
- UI test threading fixes
- Sizegroup merging (Ronaldo)
- Mask improvements (Ronaldo)
- ObjectList improvements (Johan, Ronaldo, Patrick)
- Lots of bug fixes (Johan, Ronaldo, Sidnei)
Features
========
* An MVC-derived framework of classes:
* Views, which represent the graphical display
* Controllers, which handles user interaction with the widgets
in a View.
* Delegates, combines a View and a Controller.
* Models, which are special mixins for your domain objects
* Proxies, special types of Delegate designed to implement forms
* Validation: Kiwi supports validation on different levels:
data type validation and verification on the Model/Proxy level,
View validation and hooks for visually displaying validation state.
* ObjectList widget, which provides a higher level abstraction of
GtkTreeView and all its classes (GtkTreeModel, GtkTreeViewColumn,
GtkCellRenderer) with hooks to easily integrate into the
Kiwi Framework.
* Mask suport: You can set a mask on entries to force the input to
follow a certain standard, such as zip code, social security, ip address
* Gazpacho integration for most (non-deprecated) interactive
widgets with attributes for handling validation and proxy
attributes.
* UI Test framework
Features a recorder and a player. The recorder allows you to record
different tasks, a script will be saved which will reproduce the
actions you made in the interface.
* Kiwi Tasklets
Tasklet is a small coroutines framework written by Gustavo Carneiro,
it was previously known as gtasklets.
* PyGTK utilities, to make it easier to add signals and properties to
your objects.
* i18n translation utilities, to help you translate PyGTK applications,
currently depends on gettext and intltool.
* and many other things!
Requirements
============
Python 2.3 or higher (2.4 recommended) http://www.python.org/
PyGTK 2.6.0 or higher (2.8 recommended) http://www.pygtk.org/
gazpacho 0.6.5 (svn recommenced) http://gazpacho.sicem.biz/
Documentation
=============
Kiwi provides API documentation generated by epydoc, it can be found at
http://www.async.com.br/projects/kiwi/api/
Included in the tarball are also a number of examples, which serves as a
good starting point. Keep in mind that most of them require gazpacho to
be installed.
Thanks
======
Christian Robottom Reis: Original author and design
Lorenzo Gil Sanchez: PyGTK 2.x port
Also thanks to the following people which has contributed features
or bug reports:
Ali Afshar, Henrique Romano, Daniel Saran R. da Cunha, Evandro Vale
Miquelito, Gustavo Barbieri, Gustavo Carneiro, Sidnei da Silva
Patrick O'Brien, Ronaldo Maia
Resources
=========
Homepage http://www.async.com.br/projects/kiwi/
Download http://www.async.com.br/projects/kiwi/download/
Repository http://svn.async.com.br/cgi-bin/viewcvs.cgi/kiwi/
Report a bug http://bugs.async.com.br/enter_bug.cgi?product=Kiwi
API docs http://www.async.com.br/projects/kiwi/api/
Open bugs http://tinyurl.com/cyrms
Mail. list http://www.async.com.br/mailman/listinfo/kiwi/
[1] http://en.wikipedia.org/wiki/Model-view-controller
[2] http://tinyurl.com/2ccch
[3] http://epydoc.sourceforge.net/
--
Johan Dahlin
Async Open Source
From jUrner at arcor.de Tue Apr 25 21:16:37 2006
From: jUrner at arcor.de (=?iso-8859-1?q?J=FCrgen_Urner?=)
Date: 25 Apr 2006 12:16:37 -0700
Subject: ANN: uuid-0.3.1 released
Message-ID: <1145992596.968029.81880@t31g2000cwb.googlegroups.com>
Happy to announce the release of uuid-0.3.1 (bugfix release)
What is uuid?
uuid is a python module to create RFC 4122 compatible UUIDs
The module supports generation off RFC 4122 compatible time based,
random, sha1
and md5 based UUIDs
Whats new?
x. fixed a bug where a call to uuid_nd5() and uuid_sha1() could
lead to infinite recursion
For download and documentation see http://home.arcor.de/jurner/python/
From tomerfiliba at gmail.com Tue Apr 25 22:51:39 2006
From: tomerfiliba at gmail.com (tomerfiliba at gmail.com)
Date: 25 Apr 2006 13:51:39 -0700
Subject: released: RPyC 2.50A
Message-ID: <1145998299.775841.305290@u72g2000cwu.googlegroups.com>
Remote Python Call (RPyC) version 2.50-final is about to be released in
the week or so.
meanwhile, a release candidate (2.50A) has been released to public
review -- please report bugs. i'm still working on real unit-tests for
the library, but i'm sure users can help uncover more bugs.
http://rpyc.wikispaces.com
-tomer
From mark.m.mcmahon at gmail.com Tue Apr 25 23:32:10 2006
From: mark.m.mcmahon at gmail.com (Mark Mc Mahon)
Date: Tue, 25 Apr 2006 17:32:10 -0400
Subject: ANN: pywinauto 0.3.4 released - Fixed issue with latest ctypes,
speed gains, other changes
Message-ID: <71b6302c0604251432r5ef796d2q6c4663e58b6be7c3@mail.gmail.com>
Hi,
0.3.4 release of pywinauto is now available.
pywinauto is a set of open-source (LGPL) modules for using Python as a GUI
automation 'driver' for Windows NT based Operating Systems (NT/W2K/XP).
SourceForge project page:
http://sourceforge.net/projects/pywinauto
Download from SourceForge
http://sourceforge.net/project/showfiles.php?group_id=157379
Here is the list of changes from 0.3.3:
0.3.4 Fixed issue with latest ctypes, speed gains, other changes
------------------------------------------------------------------
25-Apr-2006
* The latest version of ctypes (0.9.9.6) removed the code generator
I was using some generated code in win32functions.py (stdcall). I
was not using those functions so I just commented them out.
* Started the process of renaming methods of the ``Application`` and
``WindowSpecification`` classes. I will be converting names to
``UppercaseNames_()``. The trailing ``_`` is to disambiguate the
method names from potential Window titles.
* Updated how print_control_identifiers works so that it now always
prints the disambiguated control name. (even for single controls)
* Added __hash__ to HwndWrapper so that controls could be dictionary
keys.
* Caching various information at various points. For example I cache
how well two pieces of text match. For short scripts this has
little impact - but for larger script it could well have a major
impact.
Also caching information for controls that cannot change
e.g. TopLeveParent, Parent, etc
If you want to follow this project then please sign up to the mailing list:
https://lists.sourceforge.net/mailman/listinfo/pywinauto-users
Thanks
Mark
--------------------------------------------
Mark Mc Mahon
Manchester, NH 03110, USA
pywinauto 0.3.4
Simple Windows GUI automation with Python. (25-Apr-06)
From aahz at pythoncraft.com Wed Apr 26 05:05:01 2006
From: aahz at pythoncraft.com (Aahz)
Date: Tue, 25 Apr 2006 20:05:01 -0700
Subject: REMINDER: BayPIGgies: April 26, 7:30pm (Google)
Message-ID: <20060426030501.GA6421@panix.com>
NOTE: Special date of WEDNESDAY April 26 at Google, usual time of 7:30pm
Please show up by 7:15 so we can start the meeting on time!
This does not change the usual May meeting on May 11 at Google; stay
tuned for an announcement of that.
Special meeting! One of the lead developers of Django is in town! Jacob
Kaplan-Moss will be talking about Django at Google. He says he'll be
fine-tuning the talk until the last minute but plans to cover:
* How Django came into being -- a bit about the Journal-World, the
problems that Django was designed to solve, some bits about its
evolution, and a glance at how *we* use Django today.
* What writing Django apps look -- I'll show off some real code and
talk about each of the bits of Django's stack. This'll be the bulk
of the talk.
* What's in store for the future of Django -- there's some awesome
community work going on, as well as some under-the-radar stuff we're
working on that I'll try to preview or at least talk about.
BayPIGgies meetings alternate between IronPort (San Bruno, California)
and Google (Mountain View, California). For more information and
directions, see http://baypiggies.net/
Before the meeting, we sometimes meet at 6pm for dinner. Discussion of
dinner plans is handled on the BayPIGgies mailing list.
Advance notice: We have speakers for May. We are currently setting up
the schedule for the rest of the year. Please e-mail
baypiggies at python.org if you want to suggest an agenda (or volunteer to
give a presentation).
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
"Argue for your limitations, and sure enough they're yours." --Richard Bach
From jdavid at itaapy.com Wed Apr 26 11:41:11 2006
From: jdavid at itaapy.com (=?UTF-8?B?IkouIERhdmlkIEliw6HDsWV6Ig==?=)
Date: Wed, 26 Apr 2006 11:41:11 +0200
Subject: itools 0.13.3 released
Message-ID: <444F4037.1030008@itaapy.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
itools is a Python library, it groups a number of packages into a single
meta-package for easier development and deployment:
itools.catalog itools.i18n itools.uri
itools.cms itools.ical itools.web
itools.csv itools.resources itools.workflow
itools.datatypes itools.rss itools.xhtml
itools.gettext itools.schemas itools.xliff
itools.handlers itools.stl itools.xml
itools.html itools.tmx
Changes:
CSV
- Be strict when parsing CSV files (check all lines have the same
number of columns), by Piotr Macuk. [#263]
Catalog
- New format, much more compact.
CMS
- Speed-up write operations.
- Add datatype "Enumerate", by Herv? Cauwelier. [#304]
- Update the French translation, by Herv? Cauwelier. [#303]
Resources
- ---------
Download
http://download.ikaaro.org/itools/itools-0.13.3.tar.gz
Home
http://www.ikaaro.org/itools
Mailing list
http://in-girum.net/mailman/listinfo/ikaaro
Bug Tracker
http://bugs.ikaaro.org
- --
J. David Ib??ez
Itaapy Tel +33 (0)1 42 23 67 45
9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFET0A3qTbdUBYy+tIRAnbXAJ0ckpSdKW5oWgwUI1RBz+E+8J6+9gCggTQb
5oCka7wodMckiAyeqi8LYbI=
=kYG0
-----END PGP SIGNATURE-----
From richard at commonground.com.au Thu Apr 27 07:59:52 2006
From: richard at commonground.com.au (Richard Jones)
Date: Thu, 27 Apr 2006 15:59:52 +1000
Subject: Roundup Issue Tracker release 1.1.2
Message-ID: <3C211735-5DD7-4C9F-9512-9F1D2ECAE701@commonground.com.au>
I'm proud to release version 1.1.2 of Roundup.
Feature:
- server-ctl script uses server configuration file (sf bug 1443805)
Fixed:
- indexing may be turned off for FileClass "content" now
("content" and "type" properties are now automatically included in
the
FileClass schema where previously the "content" property was faked
and
"type" was optional)
- reduced frequency of session timestamp update
- progress display in roundup-admin reindex
- bug in menu() permission filter (sf bug 1444440)
- verbose output during import is optional now (sf bug 1475624)
- escape *all* uses of "schema" in mysql backend (sf bug 1472120)
- responses to user rego email (sf bug 1470254)
- dangling connections in session handling (sf bug 1463359)
- classhelp popup pagination forgot about "type" (sf bug 1465836)
- umask is now configurable (with the same 0002 default)
- sorting of entries in classhelp popup (sf bug 1449000)
- allow single digit seconds in date spec (sf bug 1447141)
- prevent generation of new single-digit seconds dates (sf bug 1429390)
- implement close() on all indexers (sf bug 1242477)
If you're upgrading from an older version of Roundup you *must* follow
the "Software Upgrade" guidelines given in the maintenance
documentation.
Roundup requires python 2.3 or later for correct operation.
To give Roundup a try, just download (see below), unpack and run::
python demo.py
Release info and download page:
http://cheeseshop.python.org/pypi/roundup
Source and documentation is available at the website:
http://roundup.sourceforge.net/
Mailing lists - the place to ask questions:
http://sourceforge.net/mail/?group_id=31577
About Roundup
=============
Roundup is a simple-to-use and -install issue-tracking system with
command-line, web and e-mail interfaces. It is based on the winning
design
from Ka-Ping Yee in the Software Carpentry "Track" design competition.
Note: Ping is not responsible for this project. The contact for this
project is richard at users.sourceforge.net.
Roundup manages a number of issues (with flexible properties such as
"description", "priority", and so on) and provides the ability to:
(a) submit new issues,
(b) find and edit existing issues, and
(c) discuss issues with other participants.
The system will facilitate communication among the participants by
managing
discussions and notifying interested parties when issues are edited.
One of
the major design goals for Roundup that it be simple to get going.
Roundup
is therefore usable "out of the box" with any python 2.3+
installation. It
doesn't even need to be "installed" to be operational, though a
disutils-based install script is provided.
It comes with two issue tracker templates (a classic bug/feature
tracker and
a minimal skeleton) and five database back-ends (anydbm, sqlite,
metakit,
mysql and postgresql).
From anthony at python.org Thu Apr 27 14:50:25 2006
From: anthony at python.org (Anthony Baxter)
Date: Thu, 27 Apr 2006 22:50:25 +1000
Subject: RELEASED Python 2.5 (alpha 2)
Message-ID: <200604272250.37293.anthony@python.org>
On behalf of the Python development team and the Python
community, I'm happy to announce the second alpha release
of Python 2.5.
This is an *alpha* release of Python 2.5. As such, it is not
suitable for a production environment. It is being released to
solicit feedback and hopefully discover bugs, as well as allowing
you to determine how changes in 2.5 might impact you. If you find
things broken or incorrect, please log a bug on Sourceforge.
In particular, note that changes to improve Python's support
of 64 bit systems might require authors of C extensions to change
their code. More information (as well as source distributions and
Windows installers) are available from the 2.5 website:
http://www.python.org/2.5/
Since the first alpha, a host of bug fixes and smaller new features
have been added. See the release notes (available from the 2.5
webpage) for more.
The plan from here is for either one more alpha release, or (more
likely) moving to the beta releases, then moving to a 2.5 final
release around August. PEP 356 includes the schedule and will be
updated as the schedule evolves.
The new features in Python 2.5 are described in Andrew Kuchling's
What's New In Python 2.5. It's available from the 2.5 web page.
Amongst the language features added include conditional expressions,
the with statement, the merge of try/except and try/finally into
try/except/finally, enhancements to generators to produce a
coroutine kind of functionality, and a brand new AST-based compiler
implementation.
New modules added include hashlib, ElementTree, sqlite3 and ctypes.
In addition, a new profiling module cProfile was added. In addition,
in the second alpha we have the new 'mailbox' module (a product of
last years Google Summer of Code).
Enjoy this new release,
Anthony
Anthony Baxter
anthony at python.org
Python Release Manager
(on behalf of the entire python-dev team)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-announce-list/attachments/20060427/7f603d50/attachment.pgp
From phd at phd.pp.ru Thu Apr 27 17:16:41 2006
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Thu, 27 Apr 2006 19:16:41 +0400
Subject: mimedecode.py version 2.1
Message-ID: <20060427151640.GA2387@phd.pp.ru>
Hello!
mimedecode.py
WHAT IS IT
Mail users, especially in non-English countries, often find that mail
messages arrived in different formats, with different content types, in
different encodings and charsets. Usually this is good because it allows us to
use apropriate format/encoding/whatever. Sometimes, though, some unification is
desireable. For example, one may want to put mail messages into an archive,
make HTML indicies, run search indexer, etc. In such situations converting
messages to text in one character set and skipping some binary atachmetnts is
much desireable.
Here is the solution - mimedecode.py.
This is a program to decode MIME messages. The program expects one input
file (either on command line or on stdin) which is treated as an RFC822 mesage,
and decoded to stdout. If the file is not an RFC822 message it is just piped to
stdout one-to-one. If the file is a simple RFC822 message it is just decoded as
one part. If it is a MIME message with multiple parts ("attachments") all parts
are decoded. Decoding can be controlled by command-line options.
WHAT'S NEW in version 2.1.0 (2006-04-27)
A patch by Bogdan Maryniuk :
portable way to get the default charset.
WHAT'S NEW in version 2.0.0
Major rewrite to use python email package.
WHERE TO GET
Master site: http://phd.pp.ru/Software/Python/#mimedecode
Faster mirrors: http://phd.by.ru/Software/Python/#mimedecode
http://phd2.chat.ru/Software/Python/#mimedecode
Requires: Python 2.2.2+
Recommends: configured mailcap database.
Documentation (also included in the package):
http://phd.pp.ru/Software/Python/mimedecode.txt
http://phd.by.ru/Software/Python/mimedecode.txt
http://phd2.chat.ru/Software/Python/mimedecode.txt
AUTHOR
Oleg Broytmann
COPYRIGHT
Copyright (C) 2001-2006 PhiloSoft Design
LICENSE
GPL
Oleg.
--
Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
From collinw at gmail.com Thu Apr 27 18:26:20 2006
From: collinw at gmail.com (Collin Winter)
Date: Thu, 27 Apr 2006 12:26:20 -0400
Subject: [ANNOUNCE]: functional 0.6 released
Message-ID: <43aa6ff70604270926q5844af26o4205a73b4ba7ea92@mail.gmail.com>
Hello all,
I have released version 0.6 of my functional module, a collection of
higher-order and functional programming tools for Python. Currently
offered are tools for function composition, partial function
application, plus flip, foldl, foldr, scanl and scanr functions.
Two version of the release are available: one is written in pure
Python and aims for maximum readability and portability. The other is
coded as a C extension module and is focused on raw performance.
Where to get it:
#########
functional is available from the project's website at
http://oakwinter.com/code/functional/download/
and from the Python Package Index at
http://cheeseshop.python.org/pypi/functional.
Both source tarballs and Python Eggs are available for both the pure
Python and C releases. Eggs are available for Python versions 2.3, 2.4 and 2.5.
Release Notes
########
+ flip will now reverse all non-keyword arguments, as opposed to
simply reversing the first two as it did in version 0.5 (by popular
request).
+ functional.compose now comes with an optional unpack parameter to
make up for the fact that Python functions aren't fully curried.
The unpack parameter means that you can now do something like this with compose:
>>> f(*g(*arg,**kw))
i.e., automatically unpacking g's return value and passing the result to f.
To get this functionality, you'd write something like:
>>> compose(f, g, unpack=True)(*args, **kwargs)
This was impossible with functional 0.5.
+ Weakref support has been added to flip and compose objects in the C version.
+ Sundry performance improvements for the C implementation.
As always, feedback welcome!
Collin Winter
From nnorwitz at gmail.com Fri Apr 28 19:37:11 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Fri, 28 Apr 2006 10:37:11 -0700
Subject: Summer of Code mailing list
Message-ID:
There's a new SoC mailing list.
soc2006 at python.org
You can sign up here: http://mail.python.org/mailman/listinfo/soc2006
This list is for any SoC discussion: mentors, students, idea, etc.
Student can submit applications starting May 1, so now is the time to
get students interested in your ideas!
Please pass this information along.
Cheers,
n
From steven.bethard at gmail.com Sat Apr 29 05:47:06 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 28 Apr 2006 21:47:06 -0600
Subject: python-dev Summary for 2006-01-16 through 2006-01-31
Message-ID:
Sorry the summaries are so late. We were late already, and it's taken
me a bit of time to get set up with the new python.org site. But I
should be all good now, and hopefully we'll get caught up with all the
summaries by the end of May. Hope you all weren't too depressed
without your bi-weekly python-dev updates! ;-)
python-dev Summary for 2006-01-16 through 2006-01-31
++++++++++++++++++++++++++++++++++++++++++++++++++++
.. contents::
[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2006-01-16_2006-01-31]
=============
Announcements
=============
-------------------------
Google summer internships
-------------------------
Google is looking to fill an unprecedented number of `student intern
positions`_ this (US) summer, at several US locations (Mountain View,
Santa Monica, Kirkland (Wash.), and New York). The perks are
incredible, and Google is not just looking for software development
interns - there are also product management positions, and UI design
and usability analyst positions.
Contributing thread:
- `Know anyone interested in a Google internship?
`__
.. _student intern positions: http://www.google.com/jobs/intern.html
[TAM]
-----------------------
Possible Summer of PyPy
-----------------------
Armin Rigo announced the possibility of a "Summer of PyPy", which
would follow the style of Google's "Summer of Code" in funding
students to work on various aspects of PyPy. The possibility has not
been confirmed yet, but we'll let you know when there's more info.
Contributing thread:
- `Summer of PyPy
`__
[SJB]
=========
Summaries
=========
---------------------------------------
Integers and strings in different bases
---------------------------------------
Alex Martelli requested the inverse of ``int(, )`` that
would convert an int into a string with digits in the appropriate
base. There was a lot of discussion of exactly where such
functionality should go. Among the suggested locations were:
* The str constructor, e.g. ``str(, )``
* A str classmethod, e.g. ``str.from_int(, )``
* An encoding method, e.g. ``str().encode("base")``
* A method on ints, e.g. ``.to_base()``
* A format code, e.g. ``"%b" % ``
* A builtin function, e.g. ``base(, )``
* A function in the math module, e.g. ``math.base(, )``
People seemed generally to like the builtin function or math module
function options, though there was some debate as to the best name for
the function. Guido suggested letting the proposal sit for a week or
two to see if anyone could come up with a better name or suggest a
better location for the function. (However, he seemed generally in
favor of the proposal, suggesting that hex() and oct() should be
deprecated and removed in a future version of Python.) No decisions
had been made at the time this summary was written.
Contributing threads:
- `str with base
`__
[SJB]
------------------------------------------------
PEP 355: Path - Object oriented filesystem paths
------------------------------------------------
Bj?rn Lindqvist resuscitated the idea of incorporating a Path class
based on Jason Ordenorff's path module to the standard library by
creating `PEP 355`_. There was some general discussion (and
corresponding PEP changes), with much discussion centred on the use of
"/" as a join-with-separator operator, which was eventually dropped
from the PEP.
More discussion considered whether Path should subclass string or not.
Subclassing string provides the advantage that Paths can be used in
the majority of places where strings are currently used, without
modification. However, there are many methods of strings that do not
seem appropriate for Path objects. Jason Orendorff would prefer for
Paths to not subclass strings, and a new format specifier (e.g. for
PyArg_ParseTuple()) be created for use with Paths.
There was general agreement that the utility of the module would be
highest when Path objects could be seamlessly used where string paths
were previous used. The debate centred on whether subclassing string
was the best way to do this or not. Path objects clearly are not
string objects (e.g. __iter__ and join() are nonsensical with paths).
Changing the C API so that Paths are accepted where necessary was the
suggested solution, although the PEP (at the time of writing the
summary) still subclasses Path from string.
Changing the methods from the names used by the os module and Jason's
module to ones that conform to PEP 8 was recommended. Jason explained
that the reason that there is so much cruft in his path module is that
the design is heavily skewed toward people already familiar with the
existing standard library equivalents. He feels that a standard
library Path class should have different design goals: less
redundancy, fewer methods, and PEP 8 compliant names.
.. _PEP 355: http://www.python.org/peps/pep-0355.html
Contributing threads:
- `The path module PEP
`__
- `/ as path join operator (was: Re: The path module PEP)
`__
- `/ as path join operator
`__
- `Path inherits from string
`__
- `The path module (class) PEP
`__
[TAM]
------------------------------
Including ctypes in the stdlib
------------------------------
The inclusion of ctypes in the standard library hit a snag: although
Guido pronounced that including it (with a strongly worded wording in
the documentation) was fine, ctypes includes libffi, which is built
with GPL'd tools, which is causes licensing issues. A lot of the
typical legal-advice-from-everyone-but-lawyers discussion took place,
but essentially what is required is a way to calculate the information
necessary to build libffi without the GPL'd tools. Hye-Shik Chang did
some work on this, and is working on integrating this into the ctypes
repository, so ctypes may still may it into the standard library.
Contributing threads:
- `Include ctypes into core Python?
`__
- `DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
`__
- `(libffi) Re: Copyright issue
`__
[TAM]
-----------------------------------
Improving the documentation process
-----------------------------------
Georg Brandl pointed out the new `documentation effort`_ by Fredrik
Lundh which uses a mix of HTML and PythonDoc-style markup and allows
convenient single-method links like
http://effbot.org/lib/os.path.join. Georg Brandl played around a bit
with the `CSS styling`_, however the main focus of Fredrik's effort
was to lower the threshold for user contributions. Along these lines,
he was working on an alternate content management system for editing
the Python documentation. He currently has a prototype_ available that
mirrors some of the content on python.org, though whether or not this
backend will be incorporated into python.org is as yet undecided.
.. _documentation effort: http://www.effbot.org/lib/
.. _CSS styling: http://home.in.tum.de/~brandlg/zipfile.html
.. _prototype: http://pydotorg.dyndns.org:8000/
Contributing threads:
- `New Pythondoc by effbot
`__
- `[Doc-SIG] that library reference, again
`__
[SJB]
---------------------
Updating ConfigParser
---------------------
The discussion about possible ConfigParser improvements continued,
with the typical failure to make any decisions.
As always, the options include small modifications to the existing
ConfigParser (e.g. allowing preservation of comments, order, and
whitespace), re-writing ConfigParser (perhaps based on existing
third-party versions), or providing a more sophisticated configuration
file module (either leaving ConfigParser as-is, or rewriting it to use
the new module).
Contributing threads:
- `ConfigParser to save with order
`__
- `Extension to ConfigParser
`__
- `YAML (was Re: Extension to ConfigParser)
`__
- `JSON (was: YAML)
`__
[TAM]
---------------------------------------
Introducing a basenumber abstract class
---------------------------------------
Alex Martelli proposed introducing a class, basenumber, along the
lines of the basestring class. The intention was to make it easier to
check whether or not something is a number. However, if inheriting
from basenumber was required for all new number-like objects, then the
duck-typing approach of simply implementing the appropriate interface
would no longer work. Also, since inheriting from multiple builtin
types is disallowed, a str subclass that needs to act like a number
(e.g. a symbolic type) would no longer be able to do so since it could
not also inherit from basenumber.
Guido suggested an __index__ method that would identify a type as
convertible into an integer, though without the loss of precision
allowed by __int__. More on this suggestion in the next summary.
Contributing threads:
- `basenumber redux
`__
- `index (was str with base)
`__
[SJB]
-----------------------------------
New Python website: beta.python.org
-----------------------------------
Skip Montanaro pointed out that Tim Parkin is heading up a `new
effort`_ to redesign the python.org site. The system is based on
content formatted primarily in ReST_ for easy editing, though to fully
render the pages a number of other tools are required. Tim hopes to
get these all wrapped up in setuptools_ and eggs_ so that anyone can
also see the fully rendered pages.
Also on the topic of webpage redesign, Steve Holden looked into
changing the sourceforge "Download Python" link to point to the right
place: http://www.python.org/download/. This link, however, cannot be
directly modified, so Martin v. L?wis put a small warning above it.
.. _new effort: http://beta.python.org/
.. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
.. _eggs: http://peak.telecommunity.com/DevCenter/PythonEggs
Contributing threads:
- `Python icon
`__
- `SourceForge Download Page, Subversion Home Page
`__
[SJB]
---------------------
Readline on OS X 10.4
---------------------
Thomas Heller has a problem building readline on OS X 10.4. This is a
known issue, the result of Apple shipping libedit symlinked to
readline rather than readline itself. You need to get a third party
copy of readline - Bob Ippolito made a _readline egg`_.
Alternatively, if LDFLAGS AND CPPFLAGS are set appropriately for
/opt/local/lib and opt/local/include, and the DarwinPorts copy of
readline is installed, then it will be found by setup.py.
Concerns about linking with readline (which is released under the GPL)
were raised, that explicitly requiring or checking for readline could
violate the licence. A suggestion was made that Python 3000 could
stop using readline and use an alternative instead.
.. _readline egg: http://python.org/pypi/readline
Contributing thread:
- `Building on OS X 10.4 fails
`__
[TAM]
-----------------------------
Yielding from a sub-generator
-----------------------------
Before PEP 342, there wasn't a big need for a shortcut to pass control
to a "sub-generator" because the following for-loop works well enough::
def main_generator():
...
for value in sub_generator():
yield value
but now that yield can return a value, that value might have to be
passed into sub_generator(), not to mention exceptions. Guido felt
that a syntactic solution is needed, if the problem is important
enough to be solved; a suggestion was "yield from sub_generator()".
Contributing thread:
- `yield back-and-forth?
`__
[TAM]
----------------------------------------
Using the Win32 API for stat/fstat/wstat
----------------------------------------
Martin v. L?wis wanted to switch the code for stat/fstat/wstat from
using msvcrt to the Win32 API. However, currently, when WindowsError
is raised, the errno attribute must be interpreted as a Win32 error
instead of as an errno.h error as in its superclass, OSError. The
Win32 API provides different error codes, so using these for the errno
attribute could cause some code breakage. The options seemed to be
either to break WindowsError and use the new Win32 API error codes, or
to introduce a new windows_error attribute to hold the additional
information. No decision had been made at the time this summary was
written.
Contributing thread:
- `"DOS" error codes, WindowsError, and errno
`__
[SJB]
---------------------------
Making timeit easier to use
---------------------------
Connelly Barnes was concerned that the default behavior of the timeit
module was not very useful. Since timing a function seems like the
most common use of timeit, it should be a simple operation, not a
method call with a string describing how to import the function and
then another string describing how to call it. Also, the default
behavior of 1 million iterations is not useful for any code that
cannot be repeated that many times. Instead, the number of iterations
should be calibrated as it is in the command-line version. Nick
Coghlan provided an implementation for these improvements, but it was
unclear whether or not those changes would be applied to the module.
Contributing thread:
- `timeit module
`__
[SJB]
---------------------------
Removing deprecated modules
---------------------------
The regex, regsub and timing modules have been obsolete since Python
2.0, but are still importable in Python 2.4 (regex and regsub both
generate a deprecation warning). Skip Montanaro asked when these
would be removed, and Guido said that they should be as soon as
possible.
Contributing thread:
- `When will regex really go away?
`__
[TAM]
================
Deferred Threads
================
- `Compiler warnings
`__
- `Octal literals
`__
==================
Previous Summaries
==================
- `os.path.getmtime on Windows
`__
- `Birkenfeld's gone
`__
- `Ph.D. dissertation ideas?
`__
- `Names matter.
`__
- `New PEP: Using ssize_t as the index type
`__
- `[PATCH] Fix dictionary subclass semantics whenused as global
dictionaries `__
- `from __future__ syntax changed
`__
===============
Skipped Threads
===============
- `PEP 247 and hashlib
`__
- `[Python-checkins] r42064 - python/trunk/Lib/logging/handlers.py
`__
- `pystate.c changes for Python 2.4.2
`__
- `computed goto's in ceval loop
`__
- `subwcrev.exe
`__
- `[Python-checkins] r42090 - in python/trunk: Modules/getbuildinfo.c
PCbuild/make_buildinfo.vcproj PCbuild/pcbuild.sln
PCbuild/pythoncore.vcproj
`__
- `Additions to the functional module
`__
- `PEP 343 and __context__()
`__
- `site triggering a bug in urllib2
`__
- `[Python-checkins] r42116 -
python/branches/release24-maint/Lib/unittest.py
`__
- `stabilizing builds
`__
- `building a module catalogue with buildbot
`__
- `Weekly Python Patch/Bug Summary
`__
- `Weekly Python Patch/Bug Summary (Revised)
`__
- `Long-time shy failure in test_socket_ssl
`__
- `[Python-checkins] r42185 -
python/trunk/Lib/test/test_socket_ssl.py
`__
- `(no subject)
`__
========
Epilogue
========
This is a summary of traffic on the `python-dev mailing list`_ from
January 16, 2006 through January 31, 2006.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis. An archive_ of
previous summaries is available online.
An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).
This python-dev summary is the 12th written by
the python-dev summary python-dev summary duo of Steve Bethard and Tony Meyer .
To contact us, please send email:
- Steve Bethard (steven.bethard at gmail.com)
- Tony Meyer (tony.meyer at gmail.com)
Do *not* post to comp.lang.python if you wish to reach us.
The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python. It also tries to advance
the development and use of Python. If you find the python-dev Summary
helpful please consider making a donation. You can make a donation at
http://python.org/psf/donations.html . Every cent counts so even a
small donation with a credit card, check, or by PayPal helps.
--------------------
Commenting on Topics
--------------------
To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email python-list at 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`_!
-------------------------
How to Read the Summaries
-------------------------
That this summary is written using reStructuredText_. Any unfamiliar
punctuation is probably markup for reST_ (otherwise it is probably
regular expression syntax or a typo :); you can safely ignore it. We
do suggest learning reST, though; it's simple and is accepted for
`PEP markup`_ and can be turned into many different formats like HTML
and LaTeX. Unfortunately, even though reST is standardized, the
wonders of programs that like to reformat text do not allow us to
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`_.
.. _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
.. _c.l.py:
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _PEP Markup: http://www.python.org/peps/pep-0012.html
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. _original text file:
http://www.python.org/dev/summary/2006-01-16_2006-01-31.rst
.. _archive: http://www.python.org/dev/summary/
.. _RSS feed: http://www.python.org/dev/summary/channews.rdf
From steven.bethard at gmail.com Sat Apr 29 05:47:28 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 28 Apr 2006 21:47:28 -0600
Subject: python-dev Summary for 2006-02-01 through 2006-02-15
Message-ID:
python-dev Summary for 2006-02-01 through 2006-02-15
++++++++++++++++++++++++++++++++++++++++++++++++++++
.. contents::
[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2006-02-01_2006-02-15]
=============
Announcements
=============
-----------------------------
QOTF: Quotes of the Fortnight
-----------------------------
We had a plethora (yes, I did just say plethora) of quotable quotes
this fortnight.
Martin v. L?wis on the `lambda keyword`_:
I believe that usage of a keyword with the name of a Greek letter
also contributes to people considering something broken.
Raymond Hettinger on the `learnability of Python`_:
A language suitable for beginners should be easy to learn, but it
should not leave them permanently crippled... To misquote Einstein:
The language should be as simple as possible, but no simpler.
Robert Brewer on `Pythonic syntax`_:
Community consensus on syntax is a pipe dream.
.. _lambda keyword:
http://mail.python.org/pipermail/python-dev/2006-February/060389.html
.. _learnability of Python:
http://mail.python.org/pipermail/python-dev/2006-February/060420.html
.. _Pythonic syntax:
http://mail.python.org/pipermail/python-dev/2006-February/060556.html
[SJB]
--------------------
Release plan for 2.5
--------------------
`PEP 356`_ lists the release plan for Python 2.5. Check it out for
the latest feature updates and planned release dates.
.. _PEP 356: http://www.python.org/dev/peps/pep-0356/
Contributing threads:
- `release plan for 2.5 ?
`__
- `2.5 release schedule
`__
- `2.5 PEP `__
[SJB]
----------------------------
lsprof available as cProfile
----------------------------
Armin Rigo finished his integration of the lsprof profiler. It's now
available as the cProfile module which exposes the same interface as
profile.
Contributing thread:
- `cProfile module
`__
[SJB]
---------------------
ssize_t branch merged
---------------------
Martin v. L?wis merged in the ssize_t branch (`PEP 353`_). All you
folks on 64 bit machines should now be able to index sequences using
your full address space. Enjoy!
.. _PEP 353: http://www.python.org/dev/peps/pep-0353/
Contributing threads:
- `ssize_t status (Was: release plan for 2.5 ?)
`__
- `ssize_t branch (Was: release plan for 2.5 ?)
`__
- `ssize_t branch merged
`__
[SJB]
=========
Summaries
=========
------------------------------------------------------
Rumors of lambda's death have been greatly exaggerated
------------------------------------------------------
Guido's finally given in -- the lambda expression will stay in Python
3.0. Of course, this didn't stave off another massively long thread
discussing the issue, but Guido finally killed that by providing a
pretty exhaustive list of why we should keep lambda as it is:
* No purely `syntactic change to lambda`_ is clearly a net gain over
the current syntax
* It's perfectly fine that Python's lambda is different from Lisp's
* Lambda current binding behavior is (correctly) exactly the same as a
def statement
* Allowing a block inside a lambda is never going to work because of
the need to indent the block
.. _syntactic change to lambda:
http://wiki.python.org/moin/AlternateLambdaSyntax
Contributing threads:
- `any support for a methodcaller HOF?
`__
- `Let's just *keep* lambda
`__
- `Let's send lambda to the shearing shed (Re: Let's just *keep*
lambda) `__
[SJB]
--------------
The bytes type
--------------
Guido asked for an update to `PEP 332`_, which proposed a ``bytes``
type. This spawned a massive discussion about what the bytes type
should look like and how it should interact with strings, especially
in Python 3.0 when all strings would be unicode. Pretty much everyone
agreed that bytes objects should be mutable sequences of ints in the
range(0, 256). Guido and others were also generally against a b'...'
literal for bytes, as that would confusingly suggest that bytes
objects were text-like, which they wouldn't be.
There was a fair bit of haggling over the signature of the bytes
constructor, but it seemed towards the end of the discussion that
people were coming to an agreement on ``bytes(initializer
[,encoding])``, where ``initializer`` could be a sequence of ints or a
str or unicode instance, and where ``encoding`` would be an error for
a sequence of ints, ignored for a str instance, and the encoding for a
unicode instance. Some people argued that the encoding argument was
unnecessary as unicode objects could be encoded using their .encode()
method, but Guido was concerned that, at least before Python 3.0 when
.encode() would return bytes objects, the multiple copying (one for
the encode, one for the bytes object creation) would require too much
overhead.
The default encoding for unicode objects was also a contentious point,
with people suggesting ASCII, Latin-1, and the system default
encoding. Guido argued that since Python strings don't know the
encoding that was used to create them, and since a programmer who
typed in Latin-1 would expect Latin-1 as the encoding and a programmer
who typed in UTF-8 would expect UTF-8 as the encoding, then the only
sensible solution was to encode unicode objects using the system
default encoding (which is pretty much always ASCII).
It seemed like an official PEP for the bytes type would be forthcoming.
.. _PEP 332: http://www.python.org/peps/pep-0332.html
Contributing threads:
- `PEP 332 revival in coordination with pep 349? [ Was:Re: release
plan for 2.5 ?]
`__
- `bytes type discussion
`__
- `byte literals unnecessary [Was: PEP 332 revival in coordination
with pep 349?] `__
- `bytes type needs a new champion
`__
[SJB]
--------------
Octal literals
--------------
Mattheww proposed removing octal literals, making 0640 a SyntaxError,
and modifying functions like os.chmod to take string arguments
instead, e.g. ``os.chmod(path, "0640")``. This led to a discussion
about how necessary octal literals actually are -- the only use case
mentioned in the thread was os.chmod() -- and how to improve their
syntax. For octal literals people seemed to prefer an ``0o`` or
``0c`` prefix along the lines of the ``0x`` prefix, possibly
introducing an analogous ``0b`` as binary literal syntax at the same
time. People also suggested a number of syntaxes for expressing
numeric literals in any base, but these seemed like overkill for the
problem at hand.
Contributing threads:
- `Octal literals
`__
- `Octal literals
`__
[SJB]
---------------------------------------------------
PEP 357: Allowing Any Object to be Used for Slicing
---------------------------------------------------
Travis Oliphant presented `PEP 357`_ to address some issues with the
sequence protocol. In Python 2.4 and earlier, if you defined an
integer-like type, there was no way of letting Python use instances of
your type in sequence indexing. And Python couldn't just call the
``__int__`` slot because then floats could be inappropriately used as
indices, e.g. ``range(10)[5.7]`` would be ``5``. To solve this
problem, `PEP 357`_ proposed adding an ``__index__`` slot that would
be called when a sequence was given a non-integer in a slice. Floats
would not define ``__index__`` because they could not be guaranteed to
produce an exact integer, but exact integers like those in numpy_
could define this method and then be allowable as sequence indices.
.. _PEP 357: http://www.python.org/peps/pep-0357.html
.. _numpy: http://www.numpy.org/
Contributing threads:
- `PEP for adding an sq_index slot so that any object, a or b, can be
used in X[a:b] notation
`__
- `Please comment on PEP 357 -- adding nb_index slot to
PyNumberMethods
`__
[SJB]
-----------------------------
const declarations in CPython
-----------------------------
To avoid some deprecation warnings generated by C++, Jeremy Hylton had
added ``const`` to a few CPython APIs that took ``char*`` but were
typically called by passing string literals. This generated compiler
errors when ``char**`` variables were passed to
PyArg_ParseTupleAndKeywords. Initially, people thought this could be
solved by changing ``const char **`` declarations to ``const char *
const *`` declarations, but while this was fine for C++, it did not
solve the problem for C. The end result was to remove the ``const``
declaration from the ``char **`` variables, but not the ``char *``
variables.
Contributing thread:
- `Baffled by PyArg_ParseTupleAndKeywords modification
`__
[SJB]
--------------------
asynchat and threads
--------------------
Mark Edgington presented a patch adding "thread safety" to asynchat.
Most people seemed to think mixing threads and asynchat was a bad
idea, and the thread drifted off to talking about exracting a subset
of Twisted to add to the stdlib (as a replacement for asynchat and
asyncore). People seemed generally in favor of this (if the subset
was reasonably small) but no one stepped forward to extract that
subset.
Contributing thread:
- `threadsafe patch for asynchat
`__
[SJB]
---------------------------------------------------
Approximate equality between floating point numbers
---------------------------------------------------
To make floating-point math easier for newbies, Alex Martelli proposed
math.areclose() which would take two floating point numbers with
optional tolerances and indicate whether or not they were "equal".
With a similar motivation, Smith proposed a math.nice() function which
would round floating point numbers in the same way that str() does.
Raymond Hettinger and others expressed concern over the stated use
case and suggested that hiding floating point details would only make
learning their intricacies later more difficult. A few people
suggested that math.areclose() might also be useful for experienced
floating-point users, but it seemed that the proposal probably didn't
have enough strength to get into the stdlib.
Contributing threads:
- `math.areclose ...?
`__
- `nice() `__
- `[Tutor] nice()
`__
[SJB]
-----------------------------
Eliminating compiler warnings
-----------------------------
Thomas Wouters noticed a few gcc 4.0.x warnings on amd64, and asked if
Python developers should strive to remove all warnings even if they're
harmless. Tim Peters was definitely in favor of eliminating all
warnings whenever possible, and so had Thomas Wouters unnecessarily
(for other compilers at least) initialize a variable to silence the
warning.
Contributing threads:
- `Compiler warnings
`__
- `Compiler warnings
`__
[SJB]
---------------------------------
Adding syntactic support for sets
---------------------------------
Greg Wilson asked about providing syntactic support for sets literals
and set comprehensions, e.g. ``{1, 2, 3, 4, 5}`` and ``{z for z in x
if (z % 2)}``. The set comprehension suggestion was pretty quickly
shot down as it wasn't deemed to be much of an improvement over a
generator expression in the set constructor, e.g. ``set(z for z in x
if (z % 2))``. The question of syntactic support for set literals
sparked a little more of a discussion. Some people initially
suggested that syntactic support for set literals was unnecessary as
the set constructor could be expanded, e.g ``set(1, 2, 3, 4, 5)``.
However this proposal would not be backwards compatible as it would be
unclear whether ``set('title')`` should be a set of one element or
five. Others questioned whether the syntactically supported set
literal should create a set() or a frozenset(). No one had a good
answer for this latter question, and the rest of the thread drifted
off into a miscellany of syntax suggestions.
Contributing thread:
- `syntactic support for sets
`__
[SJB]
-------------------------------
FD_SETSIZE in Windows and POSIX
-------------------------------
Revision 42253 introduced a bug in Windows sockets by assuming that
FD_SETSIZE was the maximum number of distinct file descriptors a file
descriptor set can hold, and checking for this. FD_SETSIZE is actually
the numerical magnitude of a file descriptor (which happens to
correspond to the maximum number of distinct file descriptors on POSIX
systems where fdsets are just big bit vectors). A #define,
Py_DONT_CHECK_FD_SETSIZE, was introduced so that the check could be
skipped on windows machines.
Contributing thread:
- `Pervasive socket failures on Windows
`__
[SJB]
-----------------------------
Iterators and __length_hint__
-----------------------------
In Python 2.4, a number of iterators had grown __len__ methods to
allow for some optimizations (like allocating enough space to create a
list out of them). Guido had asked for these methods to be removed and
hidden instead as an implementation detail. Originally, Raymond had
used the name ``_length_cue``, but he was convinced instead to use the
name ``__length_hint__``.
Contributing thread:
- `_length_cue()
`__
[SJB]
-----------------------------------------------
Linking with mscvrt instead of the compiler CRT
-----------------------------------------------
Martin v. L?wis suggested that on Windows, instead of linking Python
with the CRT of the compiler used to compile Python, Python should be
linked with mscvrt, the CRT that is part of the operating system.
Martin hoped that this would get rid of problems where extension
modules had to be compiled with the same compiler as the Python with
which they were to run. Unfortunately, after further investigation,
Martin had to withdraw the proposal as the platform SDK doesn't
provide an import library for msvrt.dll and mscvrt is documented as
being intended only for "system components".
Contributing thread:
- `Linking with mscvrt
`__
[SJB]
-------------------------------------------
Opening text and binary files in Python 3.0
-------------------------------------------
Guido indicated that in Python 3.0 there should be two open()
functions, one for opening text files and one for opening binary
files. The .read*() methods of text files would return unicode
objects, while the .read*() methods of binary files would return bytes
objects. People then suggested a variety of names for these functions
including:
* opentext() and openbytes()
* text.open() and bytes.open()
* file.text() and file.bytes()
Guido didn't like the tight coupling of data types and IO libraries
present in the latter two. He also expressed a preference for using
open() instead of opentext(), since it was the more common use case.
Of course, modifying open() in this way would be backwards
incompatible and would thus have to wait until Python 3.0.
Contributing thread:
- `str object going in Py3K
`__
[SJB]
--------------------------------------------
Adding additional bdist_* installation types
--------------------------------------------
Phillip Eby suggested adding bdist_deb, bdist_msi, and friends to the
standard library in Python 2.5. People seemed generally in favor of
this, though there was some discussion as to whether or not bdist_egg
should also be included. The thread then trailed off into a
discussion of the various installation behaviors on different
platforms.
Contributing thread:
- `bdist_* to stdlib?
`__
[SJB]
-------------------------------------
URL for the development documentation
-------------------------------------
Georg Brandl pointed out that while http://docs.python.org/dev/ holds
the current development documentation,
http://www.python.org/dev/doc/devel was still available. Fred Drake
indicated that it was definitely preferable to use the automatically
updated docs (http://docs.python.org/dev/) but that having them on
docs.python.org seemed wrong -- docs.python.org was established so
that queries could be made for the current stable documentation
without old docs or development docs showing up. Fred then proposed
that the current stable documentation go up at
http://www.python.org/doc/current/ and the current development
documentation go up at http://www.python.org/dev/doc/. Guido thought
that http://docs.python.org/ could possibly disappear in the new
`python.org redesign`_.
.. _python.org redesign: http://beta.python.org
Contributing threads:
- `http://www.python.org/dev/doc/devel still available
`__
- `moving content around (Re: http://www.python.org/dev/doc/devel
still available)
`__
[SJB]
------------------------------------------------
PEP 355: Path - Object oriented filesystem paths
------------------------------------------------
BJ?rn Lindqvist updated `PEP 355`_ which proposes adding the path
module to replace some of the functions in os, shutil, etc. At Guido's
request, the use of ``/`` and ``//`` operators for path concatenation
was removed, and a number of redundancies brought up in the last Path
PEP discussion were addressed (though some redundancies, e.g.
``.name`` and ``.basename()`` seem to still be present).
.. _PEP 355: http://www.python.org/peps/pep-0355.html
Contributing threads:
- `The path module PEP
`__
- `Path PEP and the division operator
`__
- `Path PEP: some comments
`__
- `Path PEP -- a couple of typos.
`__
[SJB]
-----------------------------------------
Rejection of PEP 351: The freeze protocol
-----------------------------------------
Raymond Hettinger's strong opposition to `PEP 351`_, the freeze
protocol, finally won out, and Guido rejected the PEP.
.. _PEP 351: http://www.python.org/peps/pep-0351.html
Contributing thread:
- `PEP 351 `__
[SJB]
--------------------------------------
PEP 338 - Executing Modules as Scripts
--------------------------------------
Nick Coghlan updated `PEP 338`_ to comply with the import system of
`PEP 302`_. The updated PEP includes a ``run_module()`` function which
will execute the supplied module as if it were a script (e.g. with
__name__ == "__main__"). Since it supports the `PEP 302`_ import
system, it properly handles modules in both packages and zip files.
.. _PEP 302: http://www.python.org/peps/pep-0302.html
.. _PEP 338: http://www.python.org/peps/pep-0338.html
Contributing thread:
- `PEP 338 - Executing Modules as Scripts
`__
[SJB]
-----------------------------------------------
Getting sources for a particular Python release
-----------------------------------------------
David Abrahams wanted to get the Python-2.4.2 sources from SVN but
couldn't figure out which tag to check out. The right answer for him
was http://svn.python.org/projects/python/tags/r242/ and in general it
seemed that the r tags corresponded to the
.. release.
Contributing thread:
- `How to get the Python-2.4.2 sources from SVN?
`__
[SJB]
---------------------------------------
PEP for \*args and \*\*kwargs unpacking
---------------------------------------
Thomas Wouters asked if people would be interested in a PEP to
generalize the use of \*args and \*\*kwargs to unpacking, e.g.:
* ``['a', 'b', *iterable, 'c']``
* ``a, b, *rest = range(5)``
* ``{**defaults, **args, 'fixedopt': 1}``
* ``spam(*args, 3, **kwargs, spam='extra', eggs='yes')``
People definitely wanted to see a PEP, as these or similar suggestions
have been raised a number of times. The time-table would likely be
for Python 2.6 though, so no PEP has yet been made available.
Contributing thread:
- `Generalizing *args and **kwargs
`__
[SJB]
----------------------
Tail call optimization
----------------------
In CPython, a function call requires a new execution frame, which is
expensive compared to a loop. Some langauges (notably scheme)
automically optimize tail-call recursion, so that in practice, it will
be just as fast. This can be done in CPython by using abusing
internals.
It merged into the decorator module discussion; in the end, Guido did
not want it in the standard library, in part because it would change
exception tracebacks, and in part because it would likely be very
different for other implementations (such as Jython).
Contributing thread:
- `Any interest in tail call optimization as a decorator?
`__
[Summary by Jim Jewett]
--------------------------------
Things to check before a release
--------------------------------
:
Hey, we should have changed the copyright dates to include 2006!
Yeah, and lets write ourselves a note, so that we remember next year!
Uh, where should put that reminder?
PEP 101 was used, since a new release should be at least one trigger
for verifying that things like this happened. And putting it there
reminded Georg that PEP 101 needs other updates too. (Example: It
still refers to the source code in sourceforge CVS, rather than
python.org SVN)
Contributing thread:
- `Where to put "post-it notes"?
`__
================
Deferred Threads
================
- `The decorator(s) module
`__
- `C AST to Python discussion
`__
- `bytes.from_hex() [Was: PEP 332 revival in coordination with pep
349?] `__
- `how bugfixes are handled?
`__
==================
Previous Summaries
==================
- `Extension to ConfigParser
`__
- `[PATCH] Fix dictionary subclass semantics whenused as global
dictionaries `__
===============
Skipped Threads
===============
- `YAML (was Re: Extension to ConfigParser)
`__
- `webmaster at python.org failing sender verification.
`__
- `ctypes patch (was: (libffi) Re: Copyright issue)
`__
- `ctypes patch
`__
- `Weekly Python Patch/Bug Summary
`__
- `Help with Unicode arrays in NumPy
`__
- `small floating point number problem
`__
- `Old Style Classes Goiung in Py3K
`__
- `Make error on solaris 9 x86 - error: parse error before
"upad128_t"
`__
- `Python modules should link to libpython
`__
- `Help on choosing a PEP to volunteer on it : 308, 328 or 343
`__
- `email 3.1 for Python 2.5 using PEP 8 module names
`__
- `[BULK] Python-Dev Digest, Vol 31, Issue 37
`__
- `py3k and not equal; re names
`__
- `Post-PyCon PyPy Sprint: February 27th - March 2nd 2006
`__
- `compiler.pyassem
`__
- `To know how to set "pythonpath"
`__
- `file.next() vs. file.readline()
`__
- `Fwd: Ruby/Python Continuations: Turning a block callback into a
read()-method ?
`__
- `PEP 343: Context managers a superset of decorators?
`__
- `Missing PyCon 2006
`__
- `how to upload new MacPython web page?
`__
- `A codecs nit (was Re: bytes.from_hex())
`__
========
Epilogue
========
This is a summary of traffic on the `python-dev mailing list`_ from
February 01, 2006 through February 15, 2006.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis. An archive_ of
previous summaries is available online.
An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).
This python-dev summary is the 13th written by
the swat team of Steve Bethard and Tony Meyer (no, we still can't make
a deadline).
To contact us, please send email:
- Steve Bethard (steven.bethard at gmail.com)
- Tony Meyer (tony.meyer at gmail.com)
Do *not* post to comp.lang.python if you wish to reach us.
The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python. It also tries to advance
the development and use of Python. If you find the python-dev Summary
helpful please consider making a donation. You can make a donation at
http://python.org/psf/donations.html . Every cent counts so even a
small donation with a credit card, check, or by PayPal helps.
--------------------
Commenting on Topics
--------------------
To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email python-list at 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`_!
-------------------------
How to Read the Summaries
-------------------------
That this summary is written using reStructuredText_. Any unfamiliar
punctuation is probably markup for reST_ (otherwise it is probably
regular expression syntax or a typo :); you can safely ignore it. We
do suggest learning reST, though; it's simple and is accepted for
`PEP markup`_ and can be turned into many different formats like HTML
and LaTeX. Unfortunately, even though reST is standardized, the
wonders of programs that like to reformat text do not allow us to
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`_.
.. _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
.. _c.l.py:
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _PEP Markup: http://www.python.org/peps/pep-0012.html
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. _original text file:
http://www.python.org/dev/summary/2006-02-01_2006-02-15.rst
.. _archive: http://www.python.org/dev/summary/
.. _RSS feed: http://www.python.org/dev/summary/channews.rdf
From steven.bethard at gmail.com Sat Apr 29 05:47:43 2006
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 28 Apr 2006 21:47:43 -0600
Subject: python-dev Summary for 2006-02-16 through 2006-02-28
Message-ID:
python-dev Summary for 2006-02-16 through 2006-02-28
++++++++++++++++++++++++++++++++++++++++++++++++++++
.. contents::
[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2006-02-16_2006-02-28]
=============
Announcements
=============
-----------------------
Python release schedule
-----------------------
The Python 2.5 release schedule is `PEP 356`_. The first releases are
planned for the end of March/beginning of April. Check the PEP for the
full plan of features.
.. _PEP 356: http://www.python.org/dev/peps/pep-0356/
Contributing threads:
- `2.5 PEP `__
- `2.5 release schedule
`__
- `2.4.3 for end of March?
`__
[SJB]
---------------------
Buildbot improvements
---------------------
Thanks to Benji York and Walter D?rwald, the `buildbot results page`_
now has a new CSS stylesheet that should make it a little easier to
read. (And thanks to Josiah Carlson, we should now have a Windows
buildbot slave.)
.. _buildbot results page: http://www.python.org/dev/buildbot/
Contributing threads:
- `buildbot is all green
`__
- `buildbot vs. Windows
`__
[SJB]
-------------------------------
Deprecation of multifile module
-------------------------------
The multifile module, which has been supplanted by the email module
since Python 2.2, is finally being deprecated. Though the module will
not be removed in Python 2.5, its documentation now clearly indicates
the deprecation.
Contributing thread:
- `Deprecate \`\`multifile\`\`?
`__
[SJB]
------------------------------
Win64 AMD64 binaries available
------------------------------
Martin v. L?wis has made `AMD64 binaries`_ available for the current
trunk's Python. If you're using an AMD64 machine (a.k.a. EM64T or
x64), give 'em a whirl and see how they work.
.. _amd64 binaries: http://www.dcl.hpi.uni-potsdam.de/home/loewis/
Contributing thread:
- `Win64 AMD64 (aka x64) binaries available64
`__
[SJB]
---------------------------------------------------
Javascript to adopt Python iterators and generators
---------------------------------------------------
On a slightly off-topic note, Brendan Eich has blogged_ that the next
version of Javascript will borrow iterators, generators and list
comprehensions from Python. Nice to see that the Python plague is
even spreading to other programming languages now. ;)
.. _blogged: http://weblogs.mozillazine.org/roadmap/archives/2006/02/
Contributing thread:
- `javascript "standing on Python's shoulders" as it moves
forward. `__
[SJB]
=========
Summaries
=========
---------------------------
A dict with a default value
---------------------------
Guido suggested a defaultdict type which would act like a dict, but
produce a default value when __getitem__ was called and no key
existed. The intent was to simplify code examples like::
# a dict of lists
for x in y:
d.setdefault(key, []).append(value)
# a dict of counts
for x in y:
d[key] = d.get(key, 0) + 1
where the user clearly wants to associate a single default with the
dict, but has no simple way to spell this. People quickly agreed that
the default should be specified as a function so that using ``list``
as a default could create a dict of lists, and using ``int`` as a
default could create a dict of counts.
Then the real thread began. Guido proposed adding an ``on_missing``
method to the dict API, which would be called whenever ``__getitem__``
found that the requested key was not present in the dict. The
``on_missing`` method would look for a ``default_factory`` attribute,
and try to call it if it was set, or raise a KeyError if it was not.
This would allow e.g. ``dd.default_factory = list`` to make a dict
object produce empty lists as default values, and ``del
dd.default_factory`` to revert the dict object to the standard
behavior.
However, a number of opponents worried that confusion would arise when
basic dict promises (like that ``x in d`` implies that ``x in
d.keys()`` and ``d[x]`` doesn't raise a KeyError) could be
conditionally overridden by the existence of a ``default_factory``
attribute. Others worried about complicating the dict API with yet
another method, especially one that was never meant to be called
directly (only overridden in subclasses). Eventually, Guido was
convinced that instead of modifying the builtin dict type, a new
collections.defaultdict should be introduced.
Guido then defended keeping ``on_missing`` as a method of the dict
type, noting that without ``on_missing`` any subclasses (e.g.
``collections.defaultdict``) that wanted to override the behavior for
missing keys would have to override ``__getitem__`` and pay the
penalty on every call instead of just the ones where the key wasn't
present. In the patch committed to the Python trunk, ``on_missing``
was renamed to ``__missing__`` and though no ``__missing__`` method is
defined for the dict type, if a subclass defines it, it will be called
instead of raising the usual KeyError.
Contributing threads:
- `Proposal: defaultdict
`__
- `Counter proposal: multidict (was: Proposal: defaultdict)
`__
- `Counter proposal: multidict
`__
- `defaultdict proposal round three
`__
- `defaultdict and on_missing()
`__
- `getdefault(), the real replacement for setdefault()
`__
[SJB]
-----------------------------------------
Encode and decode interface in Python 3.0
-----------------------------------------
Jason Orendorff suggested that ``bytes.encode()`` and
``text.decode()`` (where text is the name of Python 3.0's str/unicode)
should be removed in Python 3.0. Guido agreed, suggesting that Python
3.0 should have one of the following APIs for encoding and decoding:
- bytes.decode(enc) -> text
text.encode(enc) -> bytes
- text(bytes, enc) -> text
bytes(text, enc) -> bytes
There was a lot of discussion about how hard it was for beginners to
figure out the current ``.encode()`` and ``.decode()`` methods, and
Martin v. L?wis suggested that the behavior::
py> "Martin v. L?wis".encode("utf-8")
Traceback (most recent call last):
File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in
position 11: ordinal not in range(128)
would be better if replaced by Guido's suggested behavior::
py> "Martin v. L?wis".encode("utf-8")
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'str' object has no attribute 'encode'
since the user would immediately know that they had made a mistake by
trying to encode a string. However, some people felt that this problem
could be solved by simply changing the UnicodeDecodeError to something
more informative like ``ValueError: utf8 can only encode unicode
objects``.
M.-A. Lemburg felt strongly that text and bytes objects should keep
both ``.encode()`` and ``.decode()`` methods as simple interfaces to
the registered codecs. Since the codecs system handles general
encodings (not just text<->bytes encodings) he felt that ``.encode()``
and ``.decode()`` should be available on both bytes and text objects
and should be able to return whatever type the encoding deems
appropriate. Guido repeated one of his design guidelines: the return
*type* of a function should not depend on the *value* of the
arguments. Thus he would prefer that ``bytes.decode()`` only return
text and ``text.decode()`` only return bytes, regardless of the
encodings passed in. (He didn't seem to be commenting on the
architecture of the codecs module however, just the architecture of
the bytes and text types.)
Contributing threads:
- `bytes.from_hex() [Was: PEP 332 revival in coordination with pep
349?] `__
- `bytes.from_hex() [Was: PEP 332 revival in coordination with pep
349?] `__
- `str.translate vs unicode.translate (was: Re: str object going in
Py3K) `__
- `bytes.from_hex()
`__
- `str.translate vs unicode.translate
`__
[SJB]
-----------------
Writable closures
-----------------
Almann T. Goo was considering writing a PEP to allow write access to
names in nested scopes. Currently, names in nested scopes can only be
read, not written, so the following code fails with an
UnboundLocalError::
def getinc(start=0):
def incrementer(inc=1):
start += inc
return start
return incrementer
Almann suggested introducing a new declaration, along the lines of
``global``, to indicate that assignments to a name should be
interpreted as assignments to the name in the nearest enclosing scope.
Initially, he proposed the term ``use`` for this declaration, but
most of the thread participants seemed to prefer ``outer``, allowing
the function above to be written as::
def getinc(start=0):
def incrementer(inc=1):
outer start
start += inc
return start
return incrementer
A variety of syntactic variants achieving similar results were
proposed, including a way to name a function's local namespace::
def getinc(start=0):
namespace xxx
def incrementer(inc=1):
xxx.start += inc
return xxx.start
return incrementer
a way to indicate when a single use of a name should refer to the
outer scope, based on the syntax for `relative imports`_::
def getinc(start=0):
def incrementer(inc=1):
.start += inc # note the "."
return .start # note the "." (this one could be optional)
return incrementer
and the previously suggested rebinding statement, from `PEP 227`_::
def getinc(start=0):
def incrementer(inc=1):
start +:= inc # note the ":=" instead of "="
return start
return incrementer
Much like the last time this issue was brought up, "the discussion
fizzled out after having failed to reach a consensus on an obviously
right way to go about it" (Greg Ewing's quite appropriate wording).
No PEP was produced, and it didn't seem like one would soon be
forthcoming.
.. _PEP 227: http://www.python.org/peps/pep-0227.html
.. _relative imports: http://www.python.org/peps/pep-0328.html
Contributing threads:
- `PEP for Better Control of Nested Lexical Scopes
`__
- `Papal encyclical on the use of closures (Re: PEP for Better Control
of Nested Lexical Scopes)
`__
- `Using and binding relative names (was Re: PEP for Better Control of
Nested Lexical Scopes)
`__
[SJB]
---------------------------
PEP 358: The "bytes" Object
---------------------------
This week mostly wrapped up the bytes type discussion from the last
fortnight, with the introduction of `PEP 358`_: The "bytes" Object.
The PEP proposes a ``bytes`` type which:
* is a sequence of range(0, 256) int objects
* can be constructed out of lists of range(0, 256) ints
* can be constructed out of the characters of str objects
* can be constructed out of unicode objects using a specified encoding
(or the system default encoding if none is specified)
* can be constructed out of a hex string using the classmethod ``bytes.fromhex``
The bytes constructor allows an encoding for unicode objects (instead
of requiring a call to unicode.encode) so as not to require double
copying (one of encoding and one for conversion to bytes). Some
people took issue with the fact that constructor allows an encoding
for str objects, but ignores it, as this means code like ``bytes(s,
'utf-16be')`` will do a different thing for str and unicode. Ignoring
the encoding argument for str objects was apparently intended to ease
the transition from str to bytes, though it was not clear exactly how.
.. _PEP 358: http://www.python.org/peps/pep-0358.html
Contributing threads:
- `bytes type needs a new champion
`__
- `bytes type discussion
`__
- `Pre-PEP: The "bytes" object
`__
- `s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP 332 revival in
coordination with pep 349?]]
`__
- `PEP 358 (bytes type) comments
`__
[SJB]
----------------------------------
Compiling Python with MS VC++ 2005
----------------------------------
M.-A. Lemburg suggested compiling Python with the new `MS VC++ 2005`_,
especially since it's "free". There was some concern about the
stability of VS2005, and Benji York pointed out that the express
editions are only `free until November 6th`_. Fredrik Lundh pointed
out that it would be substantially more work for all the developers
who provide ready-made Windows binaries for multiple Python releases.
In the end, they decided to keep with the current compiler at least
for one more release.
.. _MS VC++ 2005: http://msdn.microsoft.com/vstudio/express/default.aspx
.. _free until November 6th:
http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx#pricing
Contributing thread:
- `Switch to MS VC++ 2005 ?!
`__
[SJB]
-----------------------
Alternate lambda syntax
-----------------------
Even though Guido already declared that Python 3.0 will keep the
current lambda syntax, Talin decided to try out the new AST and give
lambda a face-lift. With `Talin's patch`_, you can now write lambdas
like::
>>> a = (x*x given (x))
>>> a(9)
81
>>> a = (x*y given (x=3,y=4))
>>> a(9, 10)
90
>>> a(9)
36
>>> a()
12
The patch was remarkably simple, and people were suitably impressed by
the flexibility of the new AST. Of course, the patch was rejected
since Guido is now happy with the current lambda situation.
.. _Talin's patch: http://bugs.python.org/1434008
Contributing thread:
- `Adventures with ASTs - Inline Lambda
`__
[SJB]
---------------
Stateful codecs
---------------
Walter D?rwald was looking for ways to cleanly support stateful
codecs. M.-A. Lemburg suggested extending the codec registry to
maintain slots for the stateful encoders and decoders (and allowing
six-tuples to be passed in) and adding the functions
``codecs.getencoderobject()`` and ``codecs.getdecoderobject()``.
Walter D?rwald suggested that ``codecs.lookup()`` should return
objects with the following attributes:
(1) Name
(2) Encoder function
(3) Decoder function
(4) Stateful encoder factory
(5) Stateful decoder factory
(6) Stream writer factory
(7) Stream reader factory
For the sake of backwards compatibility, these objects would subclass
tuple so that they look like the old four-tuples returned by
``codecs.lookup()``. `Walter's patch`_ provides an implementation of
some of these suggestions.
.. _Walter's patch: http://bugs.python.org/1436130
Contributing thread:
- `Stateful codecs [Was: str object going in Py3K]
`__
[SJB]
---------------------------------------
operator.is*Type and user-defined types
---------------------------------------
Michael Foord pointed out that for types written in Python,
``operator.isMappingType`` and ``operator.isSquenceType`` are
essentially identical -- they both return True if ``__getitem__`` is
defined. Raymond Hettinger and Greg Ewing explained that for types
written in C, these functions can give more detailed information
because at the C level, CPython differentiates between the
``__getitem__`` of the sequence protocol and the ``__getitem__`` of
the mapping protocol.
Contributing thread:
- `operator.is*Type
`__
[SJB]
--------------------------
Python-level AST interface
--------------------------
Brett Cannon started a brief thread to discuss where to go next with
the Python AST branch. Though some of the discussion moved online at
PyCon, the major decisions were reported by Martin v. L?wis:
* The ast-objects branch (which used reference-counting instead of
arena allocation) was dropped because it seemed less maintainable and
people had agreed that exposing the C AST objects to Python was a bad
idea anyway
* Python code would have access to a "shadow tree" of the actual AST
tree, accessible by calling ``compile()`` with the flag PyCF_ONLY_AST
(0x400).
As a result, Python 2.5 now has a Python-level interface to AST objects::
>>> compile('"spam" if x else 42', '', 'eval', 0x400)
<_ast.Expression object at 0x00BA0F50>
Contributing threads:
- `C AST to Python discussion
`__
- `C AST to Python discussion
`__
- `[Python-projects] AST in Python 2.5
`__
- `Exposing the abstract syntax
`__
- `quick status report
`__
[SJB]
-------------------------------------------
Allowing property to be used as a decorator
-------------------------------------------
Georg Brandl suggested in passing that it would be nice if
``property()`` could be used as a decorator. Ian Bicking pointed out
that you can already use ``property()`` this way as long as you only
want a read-only property. However, the resulting property has no
docstring, so Alex Martelli suggested that property use the __doc__ of
its fget function if no docstring was provided. Guido approved it, and
`Georg Brandl provided a patch`_. Thus in Python 2.5, you'll be able
to write read-only properties like::
@property
def x(self):
"""The x property"""
return self._x + 42
.. _Georg Brandl provided a patch: http://bugs.python.org/1434038
Contributing threads:
- `The decorator(s) module
`__
- `The decorator(s) module
`__
[SJB]
-----------------------------------------------
Turning on unicode string literals for a module
-----------------------------------------------
Neil Schemenauer asked if it would be possible to have a ``from
__future__ import unicode_strings`` statement which would turn all
string literals into unicode literals for that module (without
requiring the usual ``u`` prefix). Currently, you can turn on this
kind of behavior for all modules using the undocumented -U
command-line switch, but there's no way of enabling it on a per-module
basis. There didn't seem to be enough momentum in the thread to
implement such a thing however.
Contributing thread:
- `from __future__ import unicode_strings?
`__
[SJB]
-------------------------------------------
Allowing cProfile to print to other streams
-------------------------------------------
Skip Montaro pointed out that the new cProfile module prints stuff to
stdout. He suggested rewriting the necessary bits to add a stream=
keyword argument where necessary and using stream.write(...) instead
of the print statements. No patch was available at the time of this
summary.
Contributing thread:
- `cProfile prints to stdout?
`__
[SJB]
--------------------------------
PEP 343 with-statement semantics
--------------------------------
Mike Bland provided an initial implementation of `PEP 343`_'s
with-statment. In writing some unit-tests for it, Guido discovered
that the implementation would not allow generators like::
@contextmanager
def foo():
try:
yield
except Exception:
pass
with foo():
1/0
to be equivalent to the corresponding in-line code::
try:
1/0
except Exception:
pass
because the PEP at the time did not allow context objects to suppress
exceptions. Guido modified the patch and the PEP to require __exit__
to reraise the exception if it didn't want it suppressed.
.. _PEP 343: http://www.python.org/peps/pep-0343.html
Contributing threads:
- `PEP 343 "with" statement patch
`__
- `with-statement heads-up
`__
[SJB]
------------------------------------
Dropping Win9x support in Python 2.6
------------------------------------
Neal Norwitz suggested that Python 2.6 no longer try to support Win9x
and WinME and updated `PEP 11`_ accordingly. There was a little
rumbling about dropping the support, but no one stepped forward to
volunteer to maintain the patches, and Guido suggested that anyone
using a 6+ year old OS should be fine using an older Python too.
.. _PEP 11: http://www.python.org/dev/peps/pep-0011/
Contributing thread:
- `Dropping support for Win9x in 2.6
`__
[SJB]
----------------------------
Removing non-Unicode support
----------------------------
Neal Norwitz suggested that the --disable-unicode switch might be a
candidate for removal in Python 2.6. A few people were mildly
concerned that the inability to remove Unicode support might make it
harder to put Python on small hand-held devices. However, many
(though not all) hand-helds already support Unicode, and currently a
number of tests already fail if you use the --disable-unicode switch,
so those who need this switch have not been actively maintaining it.
Stripping out the numerous Py_USING_UNICODE declarations would
substantially simplify some of the Python source. No final decision
had been made at the time of this summary.
Contributing thread:
- `Removing Non-Unicode Support?
`__
[SJB]
------------------------------------
Translating the Python documentation
------------------------------------
Facundo Batista had proposed translating the Library Reference and
asked about how to get notifications when the documentation was
updated (so that the translations could also be updated). Georg Brandl
suggested a post-commit hook in SVN, though this would only give
notifications at the module level. Fredrik Lundh suggested something
based on his `more dynamic library reference platform`_ so that the
notifications could indicate particular methods and functions instead.
.. _more dynamic library reference platform: http://effbot.org/zone/pyref.htm
Contributing threads:
- `Translating docs
`__
- `Fwd: Translating docs
`__
[SJB]
---------------
PEP 338 updates
---------------
At Guido's suggestion, Nick Coghlan pared down `PEP 338`_ to just the
bare bones necessary to properly implement the -m switch. That means
the runpy module will contain only a single function, run_module,
which will import the named module using the standard import
mechanism, and then execute the code in that module.
.. _PEP 338: http://www.python.org/peps/pep-0338.html
Contributing thread:
- `PEP 338 issue finalisation (was Re: 2.5 PEP)
`__
[SJB]
-----------------
Bugfix procedures
-----------------
Just a reminder of the procedure for applying bug patches in Python
(thanks to a brief thread started by Arkadiusz Miskiewicz). Anyone can
submit a patch, but it will not be committed until a committer reviews
and commits the patch. Non-committers are encouraged to review and
comment on patches, and a number of the committers have promised that
anyone who reviews and comments on at least five patches can have any
patch they like looked at.
Contributing threads:
- `how bugfixes are handled?
`__
- `how bugfixes are handled?
`__
[SJB]
--------------------------------
Removing --with-wctype-functions
--------------------------------
M.-A. Lemburg suggested removing support for --with-wctype-functions
as it makes Unicode support work in non-standard ways. Though he
announced the plan in December 2004, ``PEP 11`` wasn't updated, so
removal will be delayed until Python 2.6.
Contributing thread:
- `[Python-checkins] r42396 - peps/trunk/pep-0011.txt
`__
[SJB]
---------------------------------
Making ASCII the default encoding
---------------------------------
Neal Norwitz asked if we should finally make ASCII the default
encoding as `PEP 263`_ had promised in Python 2.3. He received only
positive responses on this, and so in Python 2.5, any file missing a
``# -*- coding: ... -*-`` declaration and using non-ASCII characters
will generate an error.
.. _PEP 263: http://www.python.org/peps/pep-0263.html
Contributing thread:
- `Making ascii the default encoding
`__
[SJB]
-------------------------------------------
PEP 308: Conditional Expressions checked in
-------------------------------------------
Thomas Wouters checked in a patch for `PEP 308`_, so Python 2.5 now
has the long-awaited conditional expressions!
.. _PEP 308: http://www.python.org/dev/peps/pep-0308/
Contributing thread:
- `PEP 308 `__
[SJB]
==================
Previous Summaries
==================
- `http://www.python.org/dev/doc/devel still available
`__
- `str object going in Py3K
`__
- `PEP 332 revival in coordination with pep 349? [ Was:Re: release
plan for 2.5 ?]
`__
- `nice() `__
- `bdist_* to stdlib?
`__
- `Please comment on PEP 357 -- adding nb_index slot to
PyNumberMethods
`__
===============
Skipped Threads
===============
- `ssize_t branch merged
`__
- `Off-topic: www.python.org
`__
- `Weekly Python Patch/Bug Summary
`__
- `2.5 - I'm ok to do release management
`__
- `Rename str/unicode to text [Was: Re: str object going in Py3K]
`__
- `Does eval() leak?
`__
- `Rename str/unicode to text [Was: Re: str object goingin Py3K]
`__
- `Test failures in test_timeout
`__
- `Rename str/unicode to text
`__
- `Copying zlib compression objects
`__
- `Serial function call composition syntax foo(x, y) -> bar() ->
baz(z) `__
- `A codecs nit
`__
- `Stackless Python sprint at PyCon 2006
`__
- `[Python-checkins] r42490 - in python/branches/release24-maint:
Lib/fileinput.py Lib/test/test_fileinput.py Misc/NEWS
`__
- `Enhancements to the fileinput module
`__
- `test_fileinput failing on Windows
`__
- `New Module: CommandLoop
`__
- `(-1)**(1/2)==1?
`__
- `documenting things [Was: Re: Proposal: defaultdict]