Hi,
at <http://dpo.gbrandl.de/contents>, you can look at a version of the 3.2
docs that has the upcoming commenting feature. JavaScript is mandatory.
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. [1]
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).
Have fun,
Georg
[1] The source for the webapp is at
<http://bitbucket.org/jacobmason/sphinx-demo-webapp>, but most of the
functionality is implemented in Sphinx trunk.
hello,
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
names)
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>
http://www.logilab.fr/http://www.logilab.org/
Informatique scientifique & et gestion de connaissances
PyBuffer_SizeFromFormat is documented and defined in abstract.h.
But I can't find an implementation of the function.
Do I overlook anything?
--
INADA Naoki <songofacandy(a)gmail.com>
The documentation for the collections Abstract Base Classes (ABCs) [1]
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 [2]
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() [3].
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 [4]. 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?
[1]:
http://docs.python.org/py3k/library/collections.html#abcs-abstract-base-cla…
[2]: http://docs.python.org/py3k/library/io.html#class-hierarchy
[3]: Possibly hurting performance by forcing .readinto() to perform the
extra allocations, copies, and deallocations required by .read().
[4]:
http://www.google.com/codesearch?hl=en&sa=N&q=BufferedIOBase++lang:python&c…
--
Daniel Stutzbach
