python-dev Summary for 2006-03-01 through 2006-03-15
Steven Bethard
steven.bethard at gmail.com
Sat Apr 29 05:47:59 CEST 2006
python-dev Summary for 2006-03-01 through 2006-03-15
++++++++++++++++++++++++++++++++++++++++++++++++++++
.. contents::
[The HTML version of this Summary is available at
http://www.python.org/dev/summary/2006-03-01_2006-03-15]
=============
Announcements
=============
-----------------------
Webstats for python.org
-----------------------
Thomas Wouters set up webalizer on dinsdale.python.org and added
webstats for all subsites of python.org:
* http://www.python.org/webstats/
* http://beta.python.org/webstats/
* http://bugs.python.org/webstats/
* http://planet.python.org/webstats/
* http://docs.python.org/webstats/
* http://svn.python.org/webstats/
Check 'em out if you're interested!
Contributing thread:
- `Webstats for www.python.org et al.
<http://mail.python.org/pipermail/python-dev/2006-March/061930.html>`__
[SJB]
---------------------------
Python 2.5 release schedule
---------------------------
The first releases scheduled for Python 2.5 are quickly approaching.
Check `PEP 356`_ for details, but the first alpha is due on April 1st.
.. _PEP 356: http://www.python.org/doc/peps/pep-0356/
Contributing thread:
- `2.5 release schedule?
<http://mail.python.org/pipermail/python-dev/2006-March/062185.html>`__
[SJB]
-----------
Py3K branch
-----------
Guido has begun work on Py3K, starting a new branch to rip out some
stuff like string exceptions and classic classes. He's trying to get
a "feel" for what Python 3.0 will look like, hopefully before his
keynote in OSCON.
Contributing thread:
- `Py3k branch - please stay out :-)
<http://mail.python.org/pipermail/python-dev/2006-March/062396.html>`__
[SJB]
-------------------------------------------
Deprecated modules going away in Python 2.5
-------------------------------------------
A number of deprecated modules will be removed in Python 2.5, including:
* reconvert.py
* regex (regexmodule.c)
* regex_syntax.py
* regsub.py
and a variety of things from lib-old. These modules have been
deprecated for a while now, and will be pulled in the next Python
release.
Contributing thread:
- `Deprecated modules going away in 2.5
<http://mail.python.org/pipermail/python-dev/2006-March/062405.html>`__
[SJB]
=========
Summaries
=========
-------------------------------
Maintaining ctypes in SVN trunk
-------------------------------
Thomas Heller put ctypes into the Python SVN repository, and with the
help of perky, Neal Norwitz and Thomas Wouters, updated it to take
advantage of the new ssize_t feature. The "official" ctypes
development will remain in its Sourceforge repository at least for a
while since this makes it easy to test ctypes on the SF compile farm.
Contributing threads:
- `ctypes is in SVN now.
<http://mail.python.org/pipermail/python-dev/2006-March/062211.html>`__
- `Developing/patching ctypes (was: Re: integrating ctypes into
python) <http://mail.python.org/pipermail/python-dev/2006-March/062243.html>`__
- `Developing/patching ctypes
<http://mail.python.org/pipermail/python-dev/2006-March/062244.html>`__
[SJB]
-----------------
Windows buildbots
-----------------
Josiah Carlson had been working on getting a buildbot slave running on
a Windows box, but eventually gave up due to crashes caused by VS.NET.
Tim Peters fought his way through the setup with a XP box, posting
`his lessons`_ to the wiki, and Trent Mick managed to follow a similar
route and setup a Win2K buildbot slave. Thanks to all who suffered
through the config -- Windows buildbot coverage looks pretty good now!
.. _his lessons: http://wiki.python.org/moin/BuildbotOnWindows
Contributing threads:
- `Another Windows buildbot slave
<http://mail.python.org/pipermail/python-dev/2006-March/062068.html>`__
- `Still looking for volunteer to run Windows buildbot
<http://mail.python.org/pipermail/python-dev/2006-March/062267.html>`__
[SJB]
-----------------------------------
Python 3.0: itr.next() or next(itr)
-----------------------------------
The end of last fortnight's defaultdict thread turned to discussing
the fate of the iterator protocol's .next() method in Python 3.0.
Greg Ewing argued that renaming .next() to .__next__() and introducing
a builtin function next() would be more consistent with the other
magic methods and also more future-proof, since the next() function
could be modified if the protocol method needed to change. Raymond
Hettinger was very strongly against this proposal, suggesting that
trading a Python-level attribute lookup for a Python-level global
lookup plus a C-level slot lookup was not a good tradeoff.
The discussion then spread out to other protocol method/function pairs
-- e.g. len() and __len__() -- and Oleg Broytmann suggested that they
could all be replaced with methods, thus saving a lookup and clearing
out the builtin namespace. Neil Schemenauer and Michael Chermside
argued against such a change, saying that the double-underscore
pattern allows new special methods to be introduced without worrying
about breaking user code, and that using functions for protocols
forces developers to use the same names when the protocols are
involved, while using methods could allow some developers to choose
different names than others.
Guido indicated that he'd like to do some usability studies to
determine whether methods or functions were more intuitive for the
various protocols.
Contributing threads:
- `defaultdict and on_missing()
<http://mail.python.org/pipermail/python-dev/2006-March/061913.html>`__
- `iterator API in Py3.0
<http://mail.python.org/pipermail/python-dev/2006-March/061927.html>`__
- `iterator API in Py3.
<http://mail.python.org/pipermail/python-dev/2006-March/061977.html>`__
- `.len() instead of __len__() (was: iterator API in Py3.0)
<http://mail.python.org/pipermail/python-dev/2006-March/062072.html>`__
- `x.len() instead of len(x) in Py3.0
<http://mail.python.org/pipermail/python-dev/2006-March/062079.html>`__
- `.len() instead of __len__() (was: iterator API inPy3.0)
<http://mail.python.org/pipermail/python-dev/2006-March/062085.html>`__
- `.len() instead of __len__() in Py3.0
<http://mail.python.org/pipermail/python-dev/2006-March/062086.html>`__
[SJB]
---------------------------
Python 3.0: base64 encoding
---------------------------
This fortnight continued discussion from the last as to whether the
base64 encoding should produce unicode or bytes objects. The encoding
is specified in `RFC 2045`_ as "designed to represent arbitrary
sequences of octets" using "a 65-character subset of US-ASCII".
Traditionally, base64 "encoding" goes from bytes to characters, and
base64 "decoding" goes from characters to bytes. But this is the
inverse of the usual unicode meanings, where "encoding" goes from
characters to bytes, and where "decoding" goes from bytes to
characters.
Thus some people felt that the recent proposal to have only
bytes.decode(), which would produce unicode, and unicode.encode(),
which would produce bytes, would be a major problem for encodings like
base64 which used the opposite terminology. A variety of proposals
ensued, including putting .encode() and .decode() on both bytes and
strings, having encode() and decode() builtins, and various ways of
putting encoding and decoding into the unicode and bytes constructors
or classmethods.
No clear solution could be agreed upon at the time.
.. _RFC 2045: http://www.ietf.org/rfc/rfc2045.txt
Contributing thread:
- `bytes.from_hex()
<http://mail.python.org/pipermail/python-dev/2006-March/061914.html>`__
[SJB]
-----------------------------
Coverity scans of Python code
-----------------------------
Ben Chelf of Coverity presented scan.coverity.com, which provides the
results of some static source code analysis looking for a variety of
code defects in a variety of open source projects, including Python.
Full access to the reports is limited to core developers, but Neal
Norwitz explained a bit what had been made available. The types of
problems reported in Python include unintialized variables, resource
leak, negative return values, using a NULL pointer, dead code, use
after free and some other similar conditions. The reports provide
information about what condition is violated and where, and according
to Neal have been high quality and accurate, though of course there
were some false positives. Generally, developers seemed quite happy
with the reports, and a number of bugs have subsequently been fixed.
Contributing threads:
- `Coverity Open Source Defect Scan of Python
<http://mail.python.org/pipermail/python-dev/2006-March/062088.html>`__
- `About "Coverity Study Ranks LAMP Code Quality"
<http://mail.python.org/pipermail/python-dev/2006-March/062322.html>`__
- `Coverity report
<http://mail.python.org/pipermail/python-dev/2006-March/062434.html>`__
[SJB]
-------------------------------
Speeding up lookups of builtins
-------------------------------
Steven Elliott was looking into reducing the cost of looking up Python
builtins. Two PEPs (`PEP 280`_ and `PEP 329`_) had already been
proposed for similar purposes, but Steven felt these were biting off
too much at once as they tried to optimize all global attribute
lookups instead of just those of builtins. His proposal would replace
the global-builtin lookup chain with an array that indexed the
builtins. A fast check for builtin shadowing would be performed before
using a builtin; if no shadowing existed, the builtin would simply be
extracted from the array, and if shadowing was present, the longer
lookup sequence would be followed.
Guido indicated that he would like to be able to assume that builtins
are not shadowed in Python 3.0, but made no comment on the particular
implementation strategy suggested. Steven Elliott promised a PEP,
though it was not yet available at the time of this summary.
.. _PEP 280: http://www.python.org/doc/peps/pep-0280/
.. _PEP 329: http://www.python.org/doc/peps/pep-0329/
Contributing thread:
- `Making builtins more efficient
<http://mail.python.org/pipermail/python-dev/2006-March/062200.html>`__
[SJB]
-------------------------------------------------
Requiring parentheses for conditional expressions
-------------------------------------------------
Upon seeing a recent checkin using conditional expressions, Jim Jewett
suggested that parentheses should be required around all conditional
expressions for the sake of readability. The usual syntax debate
ensued, and in the end it looked like the most likely result was that
`PEP 8`_ would be updated to suggest parentheses around the "test"
part of the conditional expression if it contained any internal
whitespace.
.. _PEP 8: http://www.python.org/doc/peps/pep-0008/
Contributing threads:
- `conditional expressions - add parens?
<http://mail.python.org/pipermail/python-dev/2006-March/062089.html>`__
- `(no subject)
<http://mail.python.org/pipermail/python-dev/2006-March/062101.html>`__
[SJB]
-----------------------------
Exposing a global thread lock
-----------------------------
Raymond Hettinger suggested exposing the global interpreter lock to
allow code to temporarily suspend all thread switching. Guido was
strongly against the idea as it was not portable to Jython or
IronPython and it was likely to cause deadlocks. However, there was
some support for it, and others indicated that the only way it could
cause deadlocks is if locks were acquired within the sections where
thread switching was disabled, and that even these could be avoided by
having locks raise an exception if acquired in such a section.
However, Michael Chermside explained that supporting such a thing in
Jython and IronPython would really be impossible, and suggested that
the functionality be made available in an extension module instead.
Raymond Hettinger then suggested modifying sys.setcheckinterval() to
allow thread switching to be stopped, but Martin v. Löwis explained
that even disabling this "release the GIL from time to time" setting
would not disable thread switching as, for example, the file_write
call inside a PRINT_* opcode releases the GIL around fwrite
regardless.
Contributing thread:
- `Threading idea -- exposing a global thread lock
<http://mail.python.org/pipermail/python-dev/2006-March/062346.html>`__
[SJB]
-----------------------------
Making quit and exit callable
-----------------------------
Ian Bicking resuscitated a previous proposal to make ``quit`` and
``exit`` callable objects with informative __repr__ messages like
``license`` and ``help`` already have. Georg Brandl submitted a patch
that makes ``quit`` and ``exit`` essentially synonymous with
``sys.exit`` but with better __repr__ messages. The patch was
accepted and should appear in Python 2.5.
Contributing thread:
- `quit() on the prompt
<http://mail.python.org/pipermail/python-dev/2006-March/062156.html>`__
[SJB]
---------------------
Python 3.0: Using C++
---------------------
Fredrik Lundh suggested that in Python 3.0 it might be useful to
switch to C++ instead of C for Python's implementation. This would
allow some additional type checking, some more reliable reference
counting with local variable destructors and smart pointers, and
"native" exception handling. However, it would likely make linking and
writing extension modules more difficult as C++ does not interoperate
with others as happily as C does. Stephen J. Turnbull suggested that
it might also be worth considering following the route of XEmacs --
all code must compile without warnings under both C and C++.
No final decision was made, but for the moment it looks like Python
will stick with the status quo.
Contributing thread:
- `C++ for CPython 3? (Re: str.count is slow)
<http://mail.python.org/pipermail/python-dev/2006-March/061920.html>`__
[SJB]
----------------------
A @decorator decorator
----------------------
Georg Brandl presented a `patch providing a ``decorator`` decorator`_
that would transfer a function's __name__, __doc__ and __dict__
attributes to the wrapped function. Initially, he had placed it in a
new ``decorator`` module, but a number of folks suggested that this
module and the ``functional`` module -- which currently only contains
partial() -- should be merged into a ``functools`` module. At the time
of this summary, the patch had not been applied.
.. _patch providing a ``decorator`` decorator: http://bugs.python.org/1448297
Contributing thread:
- `decorator module patch
<http://mail.python.org/pipermail/python-dev/2006-March/062290.html>`__
[SJB]
-----------------------
Expanding the use of as
-----------------------
Georg Brandl proposed that since ``as`` is finally becoming a keyword,
other statements might allow ``as`` to be used for binding a name like
the ``import`` and ``with`` statements do now. Generally people
thought that using ``as`` to name the ``while`` or ``if`` conditions
was not really that useful, especially since the parallel to ``with``
statements was pretty weak -- ``with`` statements bind the result of
the context manager's __enter__() call, not the context manager
itself.
Contributing thread:
- `"as" mania
<http://mail.python.org/pipermail/python-dev/2006-March/062128.html>`__
[SJB]
------------------------------
Relative imports in the stdlib
------------------------------
Guido made a checkin using the new `relative import feature`_ in a few
places. Because using relative imports can cause custom __import__'s
to break (because they don't take the new optional fifth argument),
Guido backed out the changes, and updated `PEP 8`_ to indicate that
absolute imports were to be preferred over relative imports whenever
possible.
.. _relative import feature: http://www.python.org/doc/peps/pep-0328/
Contributing threads:
- `Using relative imports in std lib packages ([Python-checkins]
r43033 - in python/trunk/Lib: distutils/sysconfig.py
encodings/__init__.py)
<http://mail.python.org/pipermail/python-dev/2006-March/062421.html>`__
- `[Python-checkins] r43033 - in python/trunk/Lib:
distutils/sysconfig.py encodings/__init__.py
<http://mail.python.org/pipermail/python-dev/2006-March/062427.html>`__
[SJB]
------------------------------------
Making staticmethod objects callable
------------------------------------
Nicolas Fleury suggested that staticmethod objects should be made
callable so that code like::
class A(object):
@staticmethod
def foo(): pass
bar = foo()
would work instead of compaining that staticmethod objects are not
callable. Generally, people seemed to feel that most uses of
staticmethods were better expressed as module-level functions anyway,
and so catering to odd uses of staticmethods was not something Python
needed to do.
Contributing thread:
- `Making staticmethod objects callable?
<http://mail.python.org/pipermail/python-dev/2006-March/061948.html>`__
[SJB]
----------------------------------
Adding a uuid module to the stdlib
----------------------------------
Fredrik Lundh suggested `adding Ka-Ping Yee's uuid module`_ to the
standard library. Most people were agreeable to the idea, but with
other uuid implementations around, there was some discussion about the
details. Phillip J. Eby suggested something more along the lines of
`PEAK's uuid module`_, but no final decisions were made.
.. _adding Ka-Ping Yee's uuid module: http://bugs.python.org/1368955
.. _PEAK's uuid module:
http://svn.eby-sarna.com/PEAK/src/peak/util/uuid.py?view=markup
Contributing thread:
- `how about adding ping's uuid module to the standard lib ?
<http://mail.python.org/pipermail/python-dev/2006-March/062119.html>`__
[SJB]
-------------------------------
A dict that takes key= callable
-------------------------------
Neil Schemenauer suggested providing dict variants in the collections
module that would use the ids of the objects instead of the objects
themselves. Guido suggested that it would likely be more useful to
design a dict variant that took a key= argument like list.sort() does,
and apply that key function to all keys in the dict. That would make
implementing Neil's id-dict almost trivial and support a variety of
other use-cases, like case-insensitive dicts. People seemed quite
supportive of the proposal, but no patch was available at the time of
this summary.
Contributing thread:
- `collections.idset and collections.iddict?
<http://mail.python.org/pipermail/python-dev/2006-March/062100.html>`__
[SJB]
----------------------------
Bug in __future__ processing
----------------------------
Martin Maly found `Guido's previously encountered bug`_ that Python
2.2 through 2.4 allows some assignment statements before the
``__future__`` import. Tim Peters correctly channeled Guido that this
was a bug and would be fixed in Python 2.5.
.. _Guido's previously encountered bug:
http://mail.python.org/pipermail/python-dev/2006-January/060247.html
Contributing thread:
- `Bug in from __future__ processing?
<http://mail.python.org/pipermail/python-dev/2006-March/062047.html>`__
[SJB]
-----------------------
Cleaning up string code
-----------------------
Chris Perkins noted that ``str.count()`` is substantially slower than
``unicode.count()``. Ben Cartwright and others indicated that the
source for these functions showed clearly that the unicode version had
been better optimized. Fredrik Lundh and Armin Rigo both mentioned
cleaning up the string code to avoid some of the duplication and
potentially to merge the str and unicode implementations together. At
the time of this summary, it didn't seem that any progress towards
this goal had yet been made.
Contributing thread:
- `str.count is slow
<http://mail.python.org/pipermail/python-dev/2006-February/061885.html>`__
- `str.count is slow
<http://mail.python.org/pipermail/python-dev/2006-March/061915.html>`__
[SJB]
---------------------------------------------
Freeing Python-allocated memory to the system
---------------------------------------------
Tim Peters spent his PyCon time working on `a patch by Evan Jones`_,
originally `discussed in January`_. The patch enables Python to free
memory back to the operating system so that code like::
x = []
for i in xrange(1000000):
x.append([])
del x[:]
does not continue to consume massive memory after the del statement.
Tim gave python-devvers some time to review the patch for any speed or
other issues, and then committed it.
.. _a patch by Evan Jones: http://bugs.python.org/1123430
.. _discussed in January:
http://mail.python.org/pipermail/python-dev/2005-January/051255.html
Contributing thread:
- `Arena-freeing obmalloc ready for testing
<http://mail.python.org/pipermail/python-dev/2006-March/061991.html>`__
[SJB]
------------------------------------------
Modifying the context manager __exit__ API
------------------------------------------
After thinking things over, Guido decided that the context manager
``__exit__`` method should be required to return True if it wants to
suppress an exception. This addressed the main concerns about the
previous API, that if ``__exit__`` methods were required to reraise
exceptions, a lot of ``__exit__`` methods might end up with
easily-missed bugs.
Contributing thread:
- `__exit__ API?
<http://mail.python.org/pipermail/python-dev/2006-March/062050.html>`__
[SJB]
-------------------------------
Python 3.0: default comparisons
-------------------------------
In Python 3.0, Guido plans to ditch the default ``< <= > >=``
comparisons currently provided, and only provide ``== !=`` where by
default all objects compare as unequal.
Contributing thread:
- `Keep default comparisons - or add a second set?
<http://mail.python.org/pipermail/python-dev/2006-March/062404.html>`__
[SJB]
================
Deferred Threads
================
- `[Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
<http://mail.python.org/pipermail/python-dev/2006-March/062416.html>`__
==================
Previous Summaries
==================
- `Proposal: defaultdict
<http://mail.python.org/pipermail/python-dev/2006-March/061945.html>`__
===============
Skipped Threads
===============
- `New test failure on Windows
<http://mail.python.org/pipermail/python-dev/2006-March/061928.html>`__
- `.py and .txt files missing svn:eol-style in trunk
<http://mail.python.org/pipermail/python-dev/2006-March/061929.html>`__
- `Using and binding relative names (was Re: PEP forBetter Control of
Nested Lexical Scopes)
<http://mail.python.org/pipermail/python-dev/2006-March/061934.html>`__
- `Stateful codecs [Was: str object going in Py3K]
<http://mail.python.org/pipermail/python-dev/2006-March/061946.html>`__
- `bytes thoughts
<http://mail.python.org/pipermail/python-dev/2006-March/061966.html>`__
- `wiki as scratchpad
<http://mail.python.org/pipermail/python-dev/2006-March/061967.html>`__
- `test_compiler failure
<http://mail.python.org/pipermail/python-dev/2006-March/061970.html>`__
- `DRAFT: python-dev Summary for 2006-01-16 through 2005-01-31
<http://mail.python.org/pipermail/python-dev/2006-March/061986.html>`__
- `Weekly Python Patch/Bug Summary
<http://mail.python.org/pipermail/python-dev/2006-March/061987.html>`__
- `When will regex really go away?
<http://mail.python.org/pipermail/python-dev/2006-March/061988.html>`__
- `ref leak w/except hooks
<http://mail.python.org/pipermail/python-dev/2006-March/061995.html>`__
- `Faster list comprehensions
<http://mail.python.org/pipermail/python-dev/2006-March/062030.html>`__
- `PEP 357 <http://mail.python.org/pipermail/python-dev/2006-March/062032.html>`__
- `Lib/test/test_compiler.py fails
<http://mail.python.org/pipermail/python-dev/2006-March/062035.html>`__
- `FrOSCon 2006 - Call for {Papers|Projects}
<http://mail.python.org/pipermail/python-dev/2006-March/062057.html>`__
- `Outdated Python Info on www.unicode.org (fwd)
<http://mail.python.org/pipermail/python-dev/2006-March/062058.html>`__
- `My buildbot host upgraded to OSX 10.4
<http://mail.python.org/pipermail/python-dev/2006-March/062059.html>`__
- `Slightly OT: Replying to posts
<http://mail.python.org/pipermail/python-dev/2006-March/062074.html>`__
- `New Future Keywords
<http://mail.python.org/pipermail/python-dev/2006-March/062080.html>`__
- `[Python-checkins] Python Regression Test Failures refleak (1)
<http://mail.python.org/pipermail/python-dev/2006-March/062082.html>`__
- `[Python-checkins] Python humor
<http://mail.python.org/pipermail/python-dev/2006-March/062090.html>`__
- `Two gcmodule patches
<http://mail.python.org/pipermail/python-dev/2006-March/062105.html>`__
- `Scientific Survey: Working Conditions in Open Source Projects
<http://mail.python.org/pipermail/python-dev/2006-March/062134.html>`__
- `_bsddb.c ownership
<http://mail.python.org/pipermail/python-dev/2006-March/062137.html>`__
- `str(Exception) changed, is that intended?
<http://mail.python.org/pipermail/python-dev/2006-March/062149.html>`__
- `Long-time shy failure in test_socket_ssl
<http://mail.python.org/pipermail/python-dev/2006-March/062173.html>`__
- `mail.python.org disruption
<http://mail.python.org/pipermail/python-dev/2006-March/062175.html>`__
- `Bug Day? <http://mail.python.org/pipermail/python-dev/2006-March/062191.html>`__
- `Generated code in test_ast.py
<http://mail.python.org/pipermail/python-dev/2006-March/062197.html>`__
- `fixing log messages
<http://mail.python.org/pipermail/python-dev/2006-March/062202.html>`__
- `[Python-checkins] r42929 - python/trunk/Tools/scripts/svneol.py
<http://mail.python.org/pipermail/python-dev/2006-March/062224.html>`__
- `unicodedata.c no longer compiles on Windows
<http://mail.python.org/pipermail/python-dev/2006-March/062241.html>`__
- `multidict API
<http://mail.python.org/pipermail/python-dev/2006-March/062250.html>`__
- `Google ads on python.org?
<http://mail.python.org/pipermail/python-dev/2006-March/062276.html>`__
- `libbzip2 version?
<http://mail.python.org/pipermail/python-dev/2006-March/062287.html>`__
- `PythonCore\CurrentVersion
<http://mail.python.org/pipermail/python-dev/2006-March/062297.html>`__
- `Strange behavior in Python 2.5a0 (trunk) --- possible error in AST?
<http://mail.python.org/pipermail/python-dev/2006-March/062318.html>`__
- `Why are so many built-in types inheritable?
<http://mail.python.org/pipermail/python-dev/2006-March/062334.html>`__
- `checkin r43015
<http://mail.python.org/pipermail/python-dev/2006-March/062342.html>`__
- `Topic suggestions from the PyCon feedback
<http://mail.python.org/pipermail/python-dev/2006-March/062345.html>`__
- `Another threading idea
<http://mail.python.org/pipermail/python-dev/2006-March/062383.html>`__
- `Octal literals
<http://mail.python.org/pipermail/python-dev/2006-March/062400.html>`__
- `[Python-checkins] r43022 - in python/trunk: Modules/xxmodule.c
Objects/object.c
<http://mail.python.org/pipermail/python-dev/2006-March/062407.html>`__
- `[Python-checkins] Python Regression Test Failuresrefleak (1)
<http://mail.python.org/pipermail/python-dev/2006-March/062409.html>`__
- `[Python-checkins] r43028 - python/trunk/Modules/_ctypes/cfield.c
<http://mail.python.org/pipermail/python-dev/2006-March/062413.html>`__
- `PEP 338 implemented in SVN
<http://mail.python.org/pipermail/python-dev/2006-March/062422.html>`__
========
Epilogue
========
This is a summary of traffic on the `python-dev mailing list`_ from
March 01, 2006 through March 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 15th written by
the python-dev summary pair of Steve Bethard and Tony Meyer (some day
we'll really catch up).
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-03-01_2006-03-15.rst
.. _archive: http://www.python.org/dev/summary/
.. _RSS feed: http://www.python.org/dev/summary/channews.rdf
More information about the Python-announce-list
mailing list