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 ++++++++++++++++++++++++++++++++++++++++++++++++++++
[The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-01-16_2006-01-31]
Google is looking to fill an unprecedented number of
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.
Know anyone interested in a Google internship?
.. _student intern positions: http://www.google.com/jobs/intern.html
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.
Summer of PyPy <http://mail.python.org/pipermail/python-dev/2006-January/059820.html>__
Alex Martelli requested the inverse of
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:
"%<base>b" % <number>
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.
str with base <http://mail.python.org/pipermail/python-dev/2006-January/059789.html>__
Björn Lindqvist resuscitated the idea of incorporating a Path class
based on Jason Ordenorff's path module to the standard library by
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
The path module PEP <http://mail.python.org/pipermail/python-dev/2006-January/060026.html>__
/ as path join operator (was: Re: The path module PEP) <http://mail.python.org/pipermail/python-dev/2006-January/060068.html>__
/ as path join operator <http://mail.python.org/pipermail/python-dev/2006-January/060081.html>__
Path inherits from string <http://mail.python.org/pipermail/python-dev/2006-January/060115.html>__
The path module (class) PEP <http://mail.python.org/pipermail/python-dev/2006-January/060139.html>__
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.
Include ctypes into core Python? <http://mail.python.org/pipermail/python-dev/2006-January/059766.html>__
DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15 <http://mail.python.org/pipermail/python-dev/2006-January/060099.html>__
(libffi) Re: Copyright issue <http://mail.python.org/pipermail/python-dev/2006-January/060154.html>__
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
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.
New Pythondoc by effbot <http://mail.python.org/pipermail/python-dev/2006-January/059978.html>__
[Doc-SIG] that library reference, again <http://mail.python.org/pipermail/python-dev/2006-January/060141.html>__
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).
ConfigParser to save with order <http://mail.python.org/pipermail/python-dev/2006-January/059949.html>__
Extension to ConfigParser <http://mail.python.org/pipermail/python-dev/2006-January/060138.html>__
YAML (was Re: Extension to ConfigParser) <http://mail.python.org/pipermail/python-dev/2006-January/060264.html>__
JSON (was: YAML) <http://mail.python.org/pipermail/python-dev/2006-January/060269.html>__
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.
basenumber redux <http://mail.python.org/pipermail/python-dev/2006-January/059762.html>__
index (was str with base) <http://mail.python.org/pipermail/python-dev/2006-January/059827.html>__
Skip Montanaro pointed out that Tim Parkin is heading up a
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
Python icon <http://mail.python.org/pipermail/python-dev/2006-January/059839.html>__
SourceForge Download Page, Subversion Home Page <http://mail.python.org/pipermail/python-dev/2006-January/060144.html>__
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
Building on OS X 10.4 fails <http://mail.python.org/pipermail/python-dev/2006-January/059838.html>__
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()".
yield back-and-forth? <http://mail.python.org/pipermail/python-dev/2006-January/059955.html>__
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.
"DOS" error codes, WindowsError, and errno <http://mail.python.org/pipermail/python-dev/2006-January/060243.html>__
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.
timeit module <http://mail.python.org/pipermail/python-dev/2006-January/059769.html>__
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.
When will regex really go away? <http://mail.python.org/pipermail/python-dev/2006-January/060022.html>__
Compiler warnings <http://mail.python.org/pipermail/python-dev/2006-January/060253.html>__
Octal literals <http://mail.python.org/pipermail/python-dev/2006-January/060262.html>__
os.path.getmtime on Windows <http://mail.python.org/pipermail/python-dev/2006-January/059756.html>__
Birkenfeld's gone <http://mail.python.org/pipermail/python-dev/2006-January/059757.html>__
Ph.D. dissertation ideas? <http://mail.python.org/pipermail/python-dev/2006-January/059759.html>__
Names matter. <http://mail.python.org/pipermail/python-dev/2006-January/059767.html>__
New PEP: Using ssize_t as the index type <http://mail.python.org/pipermail/python-dev/2006-January/059913.html>__
[PATCH] Fix dictionary subclass semantics whenused as global dictionaries <http://mail.python.org/pipermail/python-dev/2006-January/060024.html>__
from __future__ syntax changed <http://mail.python.org/pipermail/python-dev/2006-January/060245.html>__
PEP 247 and hashlib <http://mail.python.org/pipermail/python-dev/2006-January/059761.html>__
[Python-checkins] r42064 - python/trunk/Lib/logging/handlers.py <http://mail.python.org/pipermail/python-dev/2006-January/059777.html>__
pystate.c changes for Python 2.4.2 <http://mail.python.org/pipermail/python-dev/2006-January/059778.html>__
computed goto's in ceval loop <http://mail.python.org/pipermail/python-dev/2006-January/059865.html>__
[Python-checkins] r42090 - in python/trunk: Modules/getbuildinfo.c PCbuild/make_buildinfo.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj <http://mail.python.org/pipermail/python-dev/2006-January/059883.html>__
Additions to the functional module <http://mail.python.org/pipermail/python-dev/2006-January/059926.html>__
PEP 343 and __context__() <http://mail.python.org/pipermail/python-dev/2006-January/059943.html>__
site triggering a bug in urllib2 <http://mail.python.org/pipermail/python-dev/2006-January/059947.html>__
[Python-checkins] r42116 - python/branches/release24-maint/Lib/unittest.py <http://mail.python.org/pipermail/python-dev/2006-January/059964.html>__
stabilizing builds <http://mail.python.org/pipermail/python-dev/2006-January/060012.html>__
building a module catalogue with buildbot <http://mail.python.org/pipermail/python-dev/2006-January/060013.html>__
Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-January/060015.html>__
Weekly Python Patch/Bug Summary (Revised) <http://mail.python.org/pipermail/python-dev/2006-January/060016.html>__
Long-time shy failure in test_socket_ssl <http://mail.python.org/pipermail/python-dev/2006-January/060035.html>__
[Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py <http://mail.python.org/pipermail/python-dev/2006-January/060082.html>__
(no subject) <http://mail.python.org/pipermail/python-dev/2006-January/060259.html>__
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.
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:
Do not post to comp.lang.python if you wish to reach us.
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.
To comment on anything mentioned here, just post to
comp.lang.python_ (or email email@example.com 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
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
.. _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