[Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Tony Meyer
tony.meyer at gmail.com
Thu Jan 26 05:31:26 CET 2006
Here's the draft for the first January summary. If anyone has time to
send me/Steve comments/suggestions/corrections/additions, those will
be most welcome. The Py_ssize_t threads were particularly over my
head. As always, many thanks :)
=============
Announcements
=============
----------------------------
QOTF: Quote of the Fortnight
----------------------------
Guido, on the crashability of Python:
I'm not saying it's uncrashable. I'm saying that if you crash it,
it's a bug unless proven harebrained.
Contributing thread:
- `Include ctypes into core Python?
<http://mail.python.org/pipermail/python-dev/2006-January/059621.html>`_
[SJB]
------------------------------------
Brett Cannon looking for Ph.D. ideas
------------------------------------
Brett Cannon is looking for Python-related ideas to form the subject
of his PhD dissertation, under Eric Wohlstadter at the University of
British Columbia. He has three areas in which he has possible funding
(XML integration, game scripting support, and AOP); he is open to
grants from anyone else interested in particular Python development.
If anyone has suggestions for topics, Brett is listening!
So far:
* Phillip J. Eby mentioned that he has been doing some research on
implementing a non-traditional form of AOP in Python.
* Bill Janssen suggested a system to compile Python to AJAX.
* Steve Holden suggested a Python learning system.
* Ian Bicking suggested Boxer_ implemented for Python.
* Armin Rigo suggested PyPy related work.
* Jason Orendorff suggested collecting a downloadable corpus of Python
source code, and performing various analyses on it.
* Dennis Allison suggested interpreter structures for Python-like
languages that do not use a global interpreter lock, as well as
various other topics.
.. _Boxer: http://dewey.soe.berkeley.edu/boxer.html
Contributing thread:
- `Ph.D. dissertation ideas?
<http://mail.python.org/pipermail/python-dev/2006-January/059702.html>`__
[TAM]
---------------------------------
2.4 Documentation with Commentary
---------------------------------
Ian Bicking put an instance_ of his commenting system, Commentary_, up
against the full 2.4 documentation. If you'd like to see how the
Python docs look with user-added comments, now's your chance!
.. _instance: http://pythonpaste.org/comment/python24/
.. _Commentary: http://pythonpaste.org/commentary/
Contributing thread:
- `[Doc-SIG] that library reference, again
<http://mail.python.org/pipermail/python-dev/2006-January/059353.html>`__
[SJB]
---------------------------------------
Builds of the Development Documentation
---------------------------------------
Be sure to keep yourself up to date with the newest Python
documentation - Neal Norwitz has arranged it so that the current
Python development documentation is now automatically generated every
12 hours and placed at http://docs.python.org/dev/.
Contributing thread:
- `automated builds and tests
<http://mail.python.org/pipermail/python-dev/2006-January/059362.html>`__
[SJB]
--------------------------------
PEPs now automatically installed
--------------------------------
Martin v. Löwis has arranged for an automatic installation of PEPs_:
they will now get published in the subversion post-commit.
Contributing thread:
- `Installing PEPs
<http://mail.python.org/pipermail/python-dev/2006-January/059745.html>`__
.. _PEPs: http://www.python.org/peps
[TAM]
=========
Summaries
=========
---------------------------------------------------
Using buildbot to automate testing of Python builds
---------------------------------------------------
A buildbot_ has been setup to facilitate `automated testing of the
Python SVN`_. There are currently five slaves setup:
* Linux x86 (gentoo 2.6, glibc 2.3)
* Linux AMD64 (gentoo 2.6, glibc 2.3)
* Solaris10 sparc
* OS X 10.3 G5
* OS X 10.4 G4
Ideally, all supported platforms will be added (including OS, version,
hardware, and various configurations); the slaves are testing the
trunk and the 2.4 branch. Note that Window buildbot slaves have to
have an appropriate compiler (MS VC 7.1), otherwise it can't compile
the code; the Windows Python would also like to build several other
packages (like bz2 and Tcl/Tk). A periodic "clean build" may also be
added; there was discussion whether this should be done via a patch to
the buildbot master, via an IRC command, or with a separate scheduler.
Martin v. Löwis would rather buildbot produced static pages than act
as a web server (for security reasons). Brian Warner explained that
it once did, but was changed to make it easier to implement features
like the "Force Build" button. An explanation of the security was
given, and it seems satisfactory at the moment.
The buildbot testing has already produced results: a compiler warning
on OS X 10.3 was noticed. A discussion took place as to whether this
should be fixed (it should) and who could do it (Ronald Oussoren
volunteered, with help from Skip Montanaro).
Fredrik Lundh had been playing with "automatic module discovery" in an
attempt to figure out how complete the library reference really is,
tracking down missing reference pages and generating stubs for pages
that "should exist". He suggested that the buildbot could also run
this script; at the time of this summary this was in progress.
.. _automated testing of the Python SVN: http://www.python.org/dev/buildbot/
.. _buildbot: http://buildbot.sourceforge.net/
Contributing threads:
- `buildbot <http://mail.python.org/pipermail/python-dev/2006-January/059359.html>`__
- `Buildbot questions
<http://mail.python.org/pipermail/python-dev/2006-January/059429.html>`__
- `[Buildbot-devel] Re: buildbot
<http://mail.python.org/pipermail/python-dev/2006-January/059455.html>`__
- `Automated Python testing
<http://mail.python.org/pipermail/python-dev/2006-January/059460.html>`__
- `building a module catalogue with buildbot
<http://mail.python.org/pipermail/python-dev/2006-January/059623.html>`__
- `Buildbot: doing occasional full builds
<http://mail.python.org/pipermail/python-dev/2006-January/059643.html>`__
[TAM]
----------------------
A "Rejected Ideas" PEP
----------------------
Alexander Kozlovsky submitted a pre-PEP for the oft-repeated request
that Python do away with its explicit "self" parameter. Guido
responded with a definitive "This won't change", but didn't want to
allow the PEP to be created just to be rejected. A number of people
felt that the mailing lists weren't a sufficiently visible place for
this response, especially considering the huge number of times the
request has been presented. Thomas Wouters proposed a "Rejected
Ideas" PEP that would list some of the more commonly raised proposals
that weren't really even worthy of a PEP, with references to the
appropriate python-list or python-dev discussions. Tim Peters
nominated the alternate title "Don't Bother: PEPs Rejected Before
Being Written" which perhaps better summarizes the intent. People
seemed generally in favor of the idea, and Thomas Wouters offered to
write up a first draft indicating three major rejected ideas:
* removing the explicit "self" parameter
* upgrading the Python parser beyond a simple LL(1)
* allowing parentheses to be omitted in function calls
At the time of this summary, no PEP was yet available.
Contributing threads:
- `Draft proposal: Implicit self in Python 3.0
<http://mail.python.org/pipermail/python-dev/2006-January/059446.html>`__
- `Rejected ideas PEP (was re: Draft proposal: Implicit self in
Python 3.0) <http://mail.python.org/pipermail/python-dev/2006-January/059514.html>`__
[SJB]
-------------------------------
Using ssize_t as the index type
-------------------------------
Continuing from `last week`_, more process was made towards `PEP 353`_.
Tim Peters, Neal Norwitz, and Martin v. Löwis discussed replacing '#'
as a format character, and how this could be down in a backwards
compatible way; they also discussed how Py_ssize_t could be output
correctly in a printf-style statement. Martin suggested using %zd,
but this isn't in VC 7.1; Tim suggested that a macro be added to
pyport.h, which would use "z" where possible, and define something
else where not (e.g. Windows). Tim also suggested that PyErr_Format()
and PyString_Format() should be taught to recognize the "z" qualifier,
with the macros hidden inside the implementation of those functions.
M.-A. Lemburg pointed out other changes of output parameter types
which will cause problems in extensions, and worried that authors
wouldn't be able to get these converted in time for Python 2.5.
Martin disagreed. While code will continue to work with 32-bit
systems with little work, more needs to be done for 64-bit systems.
Martin suggested that users could continue to use 32-bit Python (since
nothing will be gained by using 64-bit anyway) until the required
changes are made. For more details, see the "Open Issues" section of
the PEP.
.. _last week:
http://www.python.org/dev/summary/2005-12-16_2005-12-31.html#using-ssize-t-as-the-index-type
.. _PEP 353: http://www.python.org/peps/pep-0353.html
Contributing threads:
- `[Python-checkins] commit of r41906 -
python/branches/ssize_t/Objects/obmalloc.c
<http://mail.python.org/pipermail/python-dev/2006-January/059381.html>`__
- `New PEP: Using ssize_t as the index type
<http://mail.python.org/pipermail/python-dev/2006-January/059437.html>`__
- `[Python-checkins] r41972 -
python/branches/ssize_t/Objects/funcobject.c
<http://mail.python.org/pipermail/python-dev/2006-January/059516.html>`__
- `Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)
<http://mail.python.org/pipermail/python-dev/2006-January/059597.html>`__
[TAM]
-------------------------------------
Adding ctypes to the standard library
-------------------------------------
Thomas Heller suggested that ctypes be included in core Python
(starting with 2.5). The common response was that while ctypes is a
useful, popular, mature module, it does make it very easy to get a
core dump, which violates the guideline that if you get a core dump
it's a bug in Python or in a third party extension or you're doing
something harebrained. On the other hand, it was pointed out that the
dl module suffers from the same problem, and is included without any
warnings (the documentation was later fixed to include warnings).
Martin v. Löwis suggested making ctypes a dynamically loaded module
(ctypes.pyd), so administrators could remove it, and
I could also make it a separate option in the Windows installer, so
administrators could opt out of installing it. Everyone seemed happy
with prominent warnings in the documentation, and so this is how it
was checked in.
Contributing thread:
- `Include ctypes into core Python?
<http://mail.python.org/pipermail/python-dev/2006-January/059604.html>`__
[TAM]
-----------------------------------------
Adding tests when no fix is yet available
-----------------------------------------
After Georg Brandl checked in a test for the compiler module without a
corresponding fix, Tim Peters reverted the change, indicating that no
check-in should ever leave the repository in such a state that
``regrtest.py -uall`` fails. The ensuing thread discussed a number of
ways of checking in a test for a bug when code to fix the bug was not
yet available. Neal Norwitz proposed adding two files to Lib/test,
outstanding_bugs.py and outstanding_crashes.py, which would include
the appropriate tests, but which would not be run under ``regrtest.py
-uall``. Some people were concerned about the maintainability of
keeping failing tests for a module separate from the other tests of
that module, so Neal Norwitz and Scott David Daniels presented a
patch_ and a recipe_ for decorators that mark individual test
functions as failing.
No official pronouncement on how failing tests should be added to the
Python test suite had been made at the time of this summary.
.. _patch: http://python.org/sf/1399935
.. _recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288
Contributing thread:
- `Checking in a broken test was: Re: [Python-checkins] r41940 -
python/trunk/Lib/test/test_compiler.py
<http://mail.python.org/pipermail/python-dev/2006-January/059481.html>`__
- `r42003 - python/trunk/Lib/test/outstanding_bugs.pypython/trunk/Lib/test/outstanding_crashes.py
<http://mail.python.org/pipermail/python-dev/2006-January/059599.html>`__
[SJB]
-------------------------------------------
Running the test suites in multiple locales
-------------------------------------------
Georg Brandl noted that unicode format modifiers were (in SVN)
incorrectly using the locale (one should always use locale.format to
get locale-aware formatting). Fredrik Lundh suggested that all test
should be run in a different locale than C to detect these bugs,
perhaps adding a "use setlocale" flag to the test runner, to simplify
this. Neal Norwitz made a patch to do this, finding a failure in
test_email and two failures in test_re.
Contributing thread:
- `locale and LC_NUMERIC
<http://mail.python.org/pipermail/python-dev/2006-January/059530.html>`__
[TAM]
-----------------------------------------------------------
Replacing the docutils directory with an svn:externals link
-----------------------------------------------------------
David Goodger replaced the static copy of docutils in the "peps"
repository with a svn:externals link to the docutils repository. There
was some concern about svn querying servers other than svn.python.org
(the docutils repository is hosted on svn.berlios.de) and about
linking to a potentially broken repository. David assured python-dev
that the svn.berlios.de server was hardly ever unreachable, and
changed the svn:externals link to select the 0.4 revision of docutils
instead of the trunk. That guaranteed a non-broken copy of docutils,
and made updating to a new revision just a simple propedit.
Contributing thread:
- `r42015 - peps/trunk
<http://mail.python.org/pipermail/python-dev/2006-January/059676.html>`__
[SJB]
--------------
Tkinter status
--------------
A brief message from Joseph Rodrigues asking about the status of
Tkinter in Python started a short thread about how Tkinter is
maintained in Python. Martin v. Löwis is the primary maintainer, and
he mainly focuses on integrating user contributions and making sure
that Python is compatible with the latest release of Tcl/Tk. New
widgets don't get wrapped automatically - if you want one supported,
you should submit a patch.
Contributing thread:
- `Tkinter <http://mail.python.org/pipermail/python-dev/2006-January/059588.html>`__
[SJB]
------------------------------------
Roadmap for ConfigParser development
------------------------------------
Once again, the output capability of ConfigParser was brought up; this
time by Facundo Bastista, who `submitted a patch`_ that orders the
output so that doctest output can be easily reliable. He pointed out
that there is `another open patch`_ that allows the user to specify
the order through an "ordered dictionary". Guido explained that he
didn't feel that it mattered, as long as the patch also allows
comments to be preserved; his preference was for everything (ordering,
blank lines, and comments) to be preserved. Tony Meyer point out some
examples of previous_ `python-dev`_ discussion_ about how ConfigParser
should be modified, and that SpamBayes_ includes a ConfigParser
subclass that allows 'surgical' editing of files.
.. _submitted a patch: http://python.org/sf/1399309
.. _another open patch: http://python.org/sf/1371075
.. _previous: http://mail.python.org/pipermail/python-dev/2004-October/049454.html
.. _python-dev:
http://mail.python.org/pipermail/python-dev/2004-October/049527.html
.. _discussion:
http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1483518
.. _SpamBayes: http://spambayes.org
Contributing thread:
- `ConfigParser to save with order
<http://mail.python.org/pipermail/python-dev/2006-January/059480.html>`__
[TAM]
-------------------------------
Patches for the logging package
-------------------------------
Shane Hathaway asked about the process for submitting patches for the
logging package. Vinay Sajip is the primary maintainer, and accepts
patches (compatible with Python 1.5.2) through sourceforge as normal,
though personal emails are appropriate if you are worried about
spending time on a patch that is not accepted. There was a brief
followup discussion about how to get the logging package to interact
nicely with external log rotation tools, including the possible
creation of a ``reopen()`` function for files, but the thread trailed
off without any solid conclusion on this issue.
Contributing thread:
- `Logging enhancements
<http://mail.python.org/pipermail/python-dev/2006-January/059566.html>`__
[SJB]
----------------------------------
os.path.getmtime() bugs on Windows
----------------------------------
Christian Tismer noted that if, in a single interactive session on
Windows, create a file, get its os.path.getmtime(), change your time
zone, and get its os.path.getmtime() again, the time stamps are
different. He asked whether there was a way to circumvent the
problem, or if a patch could be created. Tim Peters gave him a
`reference to a CodeProject page` that discusses the problem. Martin
v. Löwis has meant to work on a patch for several years; his plan is
to drop usage of msvcrt's stat(3), and instead implement os.stat in
terms of Windows API directly - this would also have the advantage
that subsecond time-stamps can be exposed. This patch would need to
be implemented twice; once for Win9X (ANSI file names) and once for
NT+ (unicode file names).
.. _reference to a CodeProject page:
http://www.codeproject.com/datetime/dstbugs.asp
Contributing thread:
- `os.path.getmtime on Windows
<http://mail.python.org/pipermail/python-dev/2006-January/059741.html>`__
[TAM]
----------------------------------------
Generating Python-ast.c and Python-ast.h
----------------------------------------
Python-ast.c and Python-ast.h are generated automatically from
Parser/asdl_c.py and then checked into Subversion. However, a ``make
distclean`` removes these files, and if you do not have a 2.2+ version
of Python available, they cannot be regenerated. The best solution
seemed to be to alter ``make distclean`` to not remove Python-ast.c
and Python-ast.h as they only need to be regenerated when the AST
definition changes, which is rather infrequent.
Contributing thread:
- `[Python-checkins] commit of r41880 -
python/trunk/Python/Python-ast.c
<http://mail.python.org/pipermail/python-dev/2006-January/059356.html>`__
[SJB]
-----------------------------------------
Allowing dict subclasses for exec globals
-----------------------------------------
Currently, the ``exec`` statement allows the locals expression (the
second expression after ``in``) to be any mapping type. The globals
expression (the first expression after ``in``) should be a dict
object, but Python does not currently raise an exception if you use a
dict subclass, though it will not call any overridden methods
correctly. `Crutcher Dunnavant presented a patch`_ that allows the
globals expression to be a dictionary subclass such that overridden
methods are called properly. Because it gives Python new
capabilities, if the patch is accepted, it will not become part of
Python until 2.5.
.. _Crutcher Dunnavant presented a patch: http://www.python.org/sf/1402289
Contributing thread:
- `[PATCH] Fix dictionary subclass semantics when used as global
dictionaries <http://mail.python.org/pipermail/python-dev/2006-January/059625.html>`__
[SJB]
==================
Previous Summaries
==================
- `When do sets shrink?
<http://mail.python.org/pipermail/python-dev/2006-January/059346.html>`__
- `Including zlib...
<http://mail.python.org/pipermail/python-dev/2006-January/059372.html>`__
- `a quit that actually quits
<http://mail.python.org/pipermail/python-dev/2006-January/059384.html>`__
- `Real time behaviour of Pythons memory management; WAS: RE:
Documentation about Python's GC,python-dev list messages referenced in
Modules/gcmodule.c notreachable anymore
<http://mail.python.org/pipermail/python-dev/2006-January/059408.html>`__
- `slight inconsistency in svn checkin email subject lines
<http://mail.python.org/pipermail/python-dev/2006-January/059355.html>`__
- `buildno (Was: [Python-checkins] commit of r41907-
python/trunk/Makefile.pre.in)
<http://mail.python.org/pipermail/python-dev/2006-January/059419.html>`__
===============
Skipped Threads
===============
- `Weekly Python Patch/Bug Summary
<http://mail.python.org/pipermail/python-dev/2006-January/059352.html>`__
- `current test problems
<http://mail.python.org/pipermail/python-dev/2006-January/059360.html>`__
- `mac memory leaks
<http://mail.python.org/pipermail/python-dev/2006-January/059367.html>`__
- `API changes
<http://mail.python.org/pipermail/python-dev/2006-January/059374.html>`__
- `file.next() vs. file.readline()
<http://mail.python.org/pipermail/python-dev/2006-January/059410.html>`__
- `Sharing between multiple interpreters and restricted mode
<http://mail.python.org/pipermail/python-dev/2006-January/059412.html>`__
- `TAR problems under Solaris
<http://mail.python.org/pipermail/python-dev/2006-January/059415.html>`__
- `bsddb broken
<http://mail.python.org/pipermail/python-dev/2006-January/059425.html>`__
- `Jython and CPython
<http://mail.python.org/pipermail/python-dev/2006-January/059434.html>`__
- `Compiler warnings for 64-bit portability problems
<http://mail.python.org/pipermail/python-dev/2006-January/059464.html>`__
- `some interesting readings
<http://mail.python.org/pipermail/python-dev/2006-January/059482.html>`__
- `Birkenfeld's gone
<http://mail.python.org/pipermail/python-dev/2006-January/059492.html>`__
- `Python-Dev Digest, Vol 29, Issue 111
<http://mail.python.org/pipermail/python-dev/2006-January/059494.html>`__
- `PyCon TX 2006: Early-bird registration ends Jan. 15!
<http://mail.python.org/pipermail/python-dev/2006-January/059511.html>`__
- `test_curses
<http://mail.python.org/pipermail/python-dev/2006-January/059528.html>`__
- `sudo security hole w/ potential Python connection
<http://mail.python.org/pipermail/python-dev/2006-January/059586.html>`__
- `Python-Dev Digest, Vol 30, Issue 32
<http://mail.python.org/pipermail/python-dev/2006-January/059587.html>`__
- `PyThreadState_Delete vs PyThreadState_DeleteCurrent
<http://mail.python.org/pipermail/python-dev/2006-January/059595.html>`__
- `Hello <http://mail.python.org/pipermail/python-dev/2006-January/059628.html>`__
- `Limiting the recursion limit
<http://mail.python.org/pipermail/python-dev/2006-January/059652.html>`__
- `PEP and stdlib
<http://mail.python.org/pipermail/python-dev/2006-January/059694.html>`__
- `DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15
<http://mail.python.org/pipermail/python-dev/2006-January/059713.html>`__
- `Unicode print/stdoutput exceptions are not nice
<http://mail.python.org/pipermail/python-dev/2006-January/059715.html>`__
- `pystate.c changes for Python 2.4.2
<http://mail.python.org/pipermail/python-dev/2006-January/059716.html>`__
- `DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31
<http://mail.python.org/pipermail/python-dev/2006-January/059717.html>`__
- `DRAFT: python-dev Summary for 2005-12-16 through2005-12-31
<http://mail.python.org/pipermail/python-dev/2006-January/059726.html>`__
- `Python icon
<http://mail.python.org/pipermail/python-dev/2006-January/059738.html>`__
More information about the Python-Dev
mailing list