Python 2.5 progress

Python 2.5 is moving steadily towards its first beta release. See PEP 356 for more details and the full schedule.

Contributing threads:

• 2.5 open issues
• nag, nag -- 2.5 open issues

Experimental wiki for editing the Python library reference

Fredrik Lundh introduced his pyref wiki which allows wiki-style editing of the Python Library Reference. In addition to providing useful links, like unique URLs for all keywords, types and special methods, the project aims to make cleaning up and rewriting parts of the Python documentation as easy as editing a wiki. If you'd like to help out, let Fredrik know your infogami user name and he can add you to the group.

Contributing threads:

• introducing the experimental pyref wiki
• introducing the experimental pyref wiki
• more pyref: continue in finally statements
• more pyref: a better term for "string conversion"
• more pyref: comparison precedence
• context guards, context entry values, context managers, context contexts

Assigning a SourceForge group to a tracker item

When opening a new patch on the SourceForge tracker, you should set "Group" to the earliest still-maintained Python version to which it applies. Currently, that means if it's a candidate for backporting, you should set the "Group" to 2.4.

Contributing thread:

• Assigning "Group" on SF tracker?

PEP 3102: Keyword-only arguments

This fortnight continued discussion from the last on Talin's PEP for keyword-only arguments. Mainly the discussion focused on the second half of his proposal which would allow positional arguments and keyword-only arguments at the same time with syntax like:

def compare(a, b, *, key=None):

The arguments for it included:

• It allows function APIs to be more strict initially to allow API evolution without breaking existing code.
• It provides better documentation for functions that currently would have to take a **kwargs.

Still, a lot of people felt uncomfortable with the idea that the writer of a function could force the callee to use keyword arguments even if the callee found positional arguments to be simpler.

Contributing thread:

• PEP 3102: Keyword-only arguments

Alternative to PEP 355 path object

Noam Raphael suggested an alternative to the path object suggested by PEP 355 which makes paths more like tuples than strings. The ensuing discussion considered a variety of options, which would have allowed code something like:

pth = Path("~/foo/bar/baz.tar.gz"):
assert pth.basepath == HOMEDIR
assert pth.dirparts == ('foo', 'bar')
assert pth.nameparts == ('baz', 'tar', 'gz')
assert pth.prefix == str(pth.basepath)
assert pth.dir == os.sep.join(pth.dirparts + ('',))
assert pth.name == os.extsep.join(pth.nameparts)

Most of the ideas were also posted to the wiki under AlternativePathClass or AlternativePathDiscussion, and a number of people asked for a PEP, but none was available at the time of this summary.

Contributing thread:

• Alternative path suggestion

Mechanics for Python sprints

Tim Peters started a discussion about the best way to handle SVN commits during a sprint. After discussing a number of heavier-handed solutions, like trying to grant commit privileges for a single branch, in the end it seemed easiest to just add all the sprinters as committers, warn them to be careful about their commits, and have folks keep an eye on python-checkins.

Contributing thread:

• Python sprint mechanics

Methods of the bytes type

Josiah Carlson asked about which str/unicode methods would still be available in Python 3000's bytes type. Guido asked for the thread to be moved to the Python-3000 list but then also suggested that "startswith", "endswith", "index", "rindex", "find", "rfind", "split", "rsplit", "join", "count", "replace", and "translate" might all be candidate methods. Josiah brought up some concerns about the bytes type not being hashable, but then Guido stepped in to ask that the debate be put on hold until the Python 3000 branch is more complete and some of these usability issues can be tested out there.

Contributing threads:

• methods on the bytes object
• methods on the bytes object
• methods on the bytes object (was: Crazy idea for str.join)

PEP 3101: Advanced String Formatting

Talin presented an updated PEP 3101, and Edward Loper brought up an issue with the current escaping strategy -- code like 'Foo\\%s' % x could not be written with the new string formatting since 'Foo\\{0}'.format(x) would read the first brace as being escaped.

Contributing threads:

• PEP 3101: Advanced String Formatting
• PEP 3101 Update

Additional support for Py_ssize_t formatting

Georg Brandl asked about formatting unsigned Py_ssize_t values with PyString_FromFormat. To support this, Tim Peters added %u, %lu, and %zu to PyString_FromFormat, PyErr_Format, and PyString_FromFormatV.

Contributing thread:

• Py_ssize_t formatting

Supporting long options: --help and --version

Heiko Wundram provided a patch to support long options for the Python interpreter in order to support --version and --help on Unix and -?, /?, /version and /help on Windows. No one seemed opposed to the idea, but at the time of this summary, the patch was still open.

Contributing thread:

• Python long command line options

Error codes on Windows

Martin v. Löwis and Marc-Andre Lemburg discussed how to include both DOS and WIN32 error codes on WindowsError objects. As part of the solution, they discussed making the Win32 error code for a specific exception available as a .winerror attribute and making all the Windows error codes available through a winerror module.

Contributing thread:

• [Python-checkins] r45925 - in python/trunk: Lib/tempfile.py Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c

Signature objects for functions

Brett Cannon asked for some discussion of signature objects that would accompany functions and describe what kind of arguments they take. In particular, he wanted to know:

• should signature objects be automatically generated, or only created at the request of a user?
• should there be a function somewhere that can determine if a particular set of arguments are valid for a function?

Some people wanted signature objects to always be available, but with the current C API, that isn't possible because functions declared in C can't be guaranteed to have the information necessary for determining a signature. Others suggested that since the signature object was only useful for introspection, it should only be available through, say, inspect.getsignature(). No PEP was available at the time of this summary.

Contributing thread:

• signature object issues (to discuss while I am out of contact)

Set complement operations

Terry Jones asked about adding efficient set complement operations to Python's builtin sets so that, say, the complement of a 999,999 element set in a 1,000,000 element universe would take up the space of 1 element, not 999,999. Most folks thought it would be better to implement this as a standalone module first before there were any considerations about adding it to the stdlib.

Contributing thread:

• Efficient set complement and operation on large/infinite sets.

Getting the weakref objects out of weakref.Weak*Dictionary objects

Fred L. Drake, Jr. presented a patch to let users get the weakref objects out of weakref.Weak*Dictionary objects. There was a brief discussion about trying to allow iteration over such dictionaries, but it looked like the patch was pretty reasonable and would soon be applied.

Contributing thread:

• New methods for weakref.Weak*Dictionary types

Python support for Windows CE

Luke Dunstan offered to maintain the port of Python to Windows CE. He got some clarifications about a number of issues, in particular that, although #ifdefs are occasionally removed to ease Python's maintenance, if they are accompanied by a record of what system and version needs them, they will not be dropped while there is an appropriate maintainer.

Contributing thread:

• Python for Windows CE

Universal binaries for Python 2.4

Ronald Oussoren asked about backporting to Python 2.4 the universal binary patches he applied to 2.5, mainly in order to avoid Apple picking up a recent copy of Python and shipping with a broken universal build like it did for python 2.3. While 2.4.4 isn't planned until after 2.5.0 (so if Apple picks up the newest version, they won't get the 2.4 line anyway), people seemed happy with the plan, and so there should be universal binary support in both Python 2.4.4 and 2.5.0.

Contributing thread:

• python 2.4 and universal binaries

Commenting on Topics

To comment on anything mentioned here, just post to comp.lang.python (or email python-list@python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join python-dev!

How to Read the Summaries

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.