at <http://dpo.gbrandl.de/contents>, you can look at a version of the 3.2
I've switched on anonymous comments for testing, but usually at least
comments from anonymous users can be moderated. Be sure to test the
"propose a change" feature too. Login currently allows OpenID exclusively.
Credits go to Jacob Mason, whose GSOC project is responsible for almost all
of what you see there. 
Please test on a smaller page, such as <http://dpo.gbrandl.de/library/math>,
there is currently a speed issue with larger pages. (Helpful tips from
JS experts are welcome.)
Other things I have to do before this can go live:
* reuse existing logins from either wiki or tracker?
* (re)Captcha integration for anonymous comments
* easier moderation (currently emails are sent on new comments)
* facility for (semi)automatic applying of proposals (once Hg is live, this
should be easy to do due to the separation between commit and merge)
* allow commenting on code blocks (figure out where to place the "bubble")
Any feedback is appreciated (I'd suggest mailing it to doc-SIG only, to avoid
cluttering up python-dev).
 The source for the webapp is at
<http://bitbucket.org/jacobmason/sphinx-demo-webapp>, but most of the
functionality is implemented in Sphinx trunk.
working on Pylint, we have a lot of voluntary corrupted files to test
Pylint behavior; for instance
$ cat /home/emile/var/pylint/test/input/func_unknown_encoding.py
# -*- coding: IBO-8859-1 -*-
""" check correct unknown encoding declaration
__revision__ = 'éééé'
and we try to find that module :
find_module('func_unknown_encoding', None). But python3 raises SyntaxError
in that case ; it didn't raise SyntaxError on python2 nor does so on our
func_nonascii_noencoding and func_wrong_encoding modules (with obvious
Python 3.2a2 (r32a2:84522, Sep 14 2010, 15:22:36)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from imp import find_module
>>> find_module('func_unknown_encoding', None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SyntaxError: encoding problem: with BOM
>>> find_module('func_wrong_encoding', None)
(<_io.TextIOWrapper name=5 encoding='utf-8'>, 'func_wrong_encoding.py',
('.py', 'U', 1))
>>> find_module('func_nonascii_noencoding', None)
(<_io.TextIOWrapper name=6 encoding='utf-8'>,
'func_nonascii_noencoding.py', ('.py', 'U', 1))
So what is the reason of this selective behavior?
Furthermore, there is BOM in our func_unknown_encoding.py module.
Emile Anclin <emile.anclin(a)logilab.fr>
Informatique scientifique & et gestion de connaissances
The documentation for the collections Abstract Base Classes (ABCs) 
contains a table listing all of the collections ABCs, their parent classes,
their abstract methods, and the methods they provide. This table makes it
very easy to figure out which methods I must override when I derive from one
of the ABCs, as well as which methods will be provided for me.
I'm working on a similar table for the I/O ABCs (
http://bugs.python.org/issue10589). The existing documentation 
describes the methods of each class but doesn't describe which methods
provide a meaningful implementation and which methods a user should
override. If I want to inherit from one of the I/O ABCs, I have to go
poking into Lib/_pyio.py to figure out which methods I need to override.
While starting to examine the I/O ABCs, I discovered that there are
some inconsistencies. For example, RawIOBase provides .read() if the
subclass provides .readinto(). BufferedIOBase does the opposite; it
provides .readinto() if the subclass provides .read() .
I would like to fix some of these inconsistencies. However, this will be a
backwards-incompatible change. A Google Code Search suggests that the ABCs
are currently only used within the standard library . Just to be clear,
the changes would NOT impact code that merely uses I/O objects; they would
only impact code that implements I/O by subclassing one of the I/O ABCs and
depending on features that are currently undocumented.
Does anyone have any categorical objections?
: Possibly hurting performance by forcing .readinto() to perform the
extra allocations, copies, and deallocations required by .read().