[Python-Dev] DRAFT: python-dev summary for 2006-05-01 to 2006-05-15 (original) (raw)

Steven Bethard steven.bethard at gmail.com
Tue Jun 13 10:17:53 CEST 2006

Ok, here's the frist half or May. I'd almost feel like I was catching up if there wasn't going to be another summary waiting for me in two days. ;-)

As always, please look it over and let me know if you have any corrections/comments.

Thanks!

============= Announcements

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.

.. _PEP 356: http://www.python.org/dev/peps/pep-0356/

Contributing threads:

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.

.. _pyref wiki: http://pyref.infogami.com/ .. _Fredrik: fredrik at effbot.org

Contributing threads:

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:

========= Summaries

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:

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:

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.

.. _PEP 355: http://www.python.org/dev/peps/pep-0355/ .. _AlternativePathClass: http://wiki.python.org/moin/AlternativePathClass .. _AlternativePathDiscussion: http://wiki.python.org/moin/AlternativePathDiscussion

Contributing thread:

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:

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.

.. _Python-3000 list: http://mail.python.org/mailman/listinfo/python-3000

Contributing threads:

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.

.. _PEP 3101: http://www.python.org/dev/peps/pep-3101/

Contributing threads:

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:

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.

.. _patch to support long options: http://bugs.python.org/1481112

Contributing thread:

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:

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:

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:

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:

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.

.. _patch to let users get the weakref objects out: http://bugs.python.org/1479988

Contributing thread:

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:

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:

================ Deferred Threads

================== Previous Summaries

=============== Skipped Threads

More information about the Python-Dev mailing list