Mailman 3 November 2015 - docs

[issue17264] Update Building C and C++ Extensions with distutils documentation
by Berker Peksag 09 Apr '16

09 Apr '16

New submission from Berker Peksag: I have removed all mentions about Python 1.4 and 2.0 from the Doc/extending/building.rst. The Demo/embed/demo.c file has been removed in 3.x, so I used "_spammodule.c" convention in the examples. The patch also fixes all the PEP 8 violations in the setup.py examples. ---------- assignee: docs@python components: Documentation files: extending_building.diff keywords: patch messages: 182580 nosy: berker.peksag, docs@python priority: normal severity: normal status: open title: Update Building C and C++ Extensions with distutils documentation versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file29139/extending_building.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17264> _______________________________________

3 3

[issue18820] json.dump() ignores its 'default' option when serializing dictionary keys
by July Tikhonov 08 Apr '16

08 Apr '16

New submission from July Tikhonov: According to documentation of json.dump(), concerning its 'default' option: default(obj) is a function that should return a serializable version of obj or raise TypeError. The default simply raises TypeError. But this function is actually never applied to serialized dictionary keys: >>> def default(obj): ... if isinstance(obj, bytes): ... return obj.decode('ascii') ... raise ValueError ... >>> json.dumps(b'asdf') Traceback (most recent call last): ... TypeError: b'asdf' is not JSON serializable >>> json.dumps(b'asdf', default=default) '"asdf"' >>> json.dumps({b'asdf' : 1}, default=default) Traceback (most recent call last): ... TypeError: keys must be a string >>> json.dumps({1 : b'asdf'}, default=default) '{"1": "asdf"}' (bytes are used purely for the purpose of example) Such behavior should be either documented or corrected. Patch correcting python implementation of json attached. ---------- assignee: docs@python components: Documentation, Library (Lib) files: json-default-dict-keys.diff keywords: patch messages: 195957 nosy: docs@python, july priority: normal severity: normal status: open title: json.dump() ignores its 'default' option when serializing dictionary keys type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file31436/json-default-dict-keys.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18820> _______________________________________

6 9

[issue23758] Improve documenation about num_params in sqlite3 create_function and create_aggregate
by Cédric Krier 27 Mar '16

27 Mar '16

New submission from Cédric Krier: num_params must have the value -1 for any number of arguments see https://www.sqlite.org/c3ref/create_function.html ---------- assignee: docs@python components: Documentation files: sqlite3_doc.patch keywords: patch messages: 239104 nosy: ced, docs@python priority: normal severity: normal status: open title: Improve documenation about num_params in sqlite3 create_function and create_aggregate type: enhancement Added file: http://bugs.python.org/file38664/sqlite3_doc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23758> _______________________________________

3 3

[issue15117] Please document top-level sqlite3 module variables
by wchlm 27 Mar '16

27 Mar '16

New submission from wchlm <shenkin(a)gmail.com>: sqlite3 top-level variables, such as version, sqlite_version, version_info, and sqlite_version_info are all useful for Python users of the module -- even essential at times. Yet there is no mention of them in the Py 2.7.3 documentation. dir(sqlite3) reveals a longer list. It would be good if someone with a deeper knowledge of the module could assemble a list of useful items and add them to the sqlite3 documentation. ---------- assignee: docs@python components: Documentation messages: 163285 nosy: docs@python, shenkin priority: normal severity: normal status: open title: Please document top-level sqlite3 module variables versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15117> _______________________________________

4 3

[issue19164] Update uuid.UUID TypeError exception: integer should not be an argument.
by Marco Buccini 20 Mar '16

20 Mar '16

New submission from Marco Buccini: When you try to use uuid.UUID() without arguments you get a TypeError exception saying that you can actually use an integer (while you cannot). Python 2.6.8 (default, Apr 26 2013, 16:24:53) [GCC 4.6.3] on linux2 >>> uuid.UUID() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/uuid.py", line 129, in __init__ raise TypeError('need one of hex, bytes, bytes_le, fields, or int') TypeError: need one of hex, bytes, bytes_le, fields, or int >>> uuid.UUID(uuid.uuid4().int) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/uuid.py", line 131, in __init__ hex = hex.replace('urn:', '').replace('uuid:', '') AttributeError: 'long' object has no attribute 'replace' So, let's check with an integer - maybe an int has 'replace'. >>> uuid.UUID(1231231) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/uuid.py", line 131, in __init__ hex = hex.replace('urn:', '').replace('uuid:', '') AttributeError: 'int' object has no attribute 'replace' No, it doesn't. Anyway, with a propery hex value, it works (of course!). >>> uuid.UUID(uuid.uuid4().hex) UUID('89b1283d-c32e-4b8a-a9e3-a699445fdd4d') ---------- assignee: docs@python components: Documentation messages: 198943 nosy: docs@python, makronized priority: normal severity: normal status: open title: Update uuid.UUID TypeError exception: integer should not be an argument. type: behavior versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19164> _______________________________________

9 8

[issue24918] Docs layout bug
by asldkjfn 13 Mar '16

13 Mar '16

New submission from asldkjfn: Green bars cover yellow text box. https://docs.python.org/2/faq/windows.html ---------- assignee: docs@python components: Documentation messages: 249018 nosy: docs@python, reag priority: normal severity: normal status: open title: Docs layout bug versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24918> _______________________________________

6 9

[issue21910] File protocol should document if writelines must handle generators sensibly
by Jan Kanis 12 Mar '16

12 Mar '16

New submission from Jan Kanis: The resolution of issue 5445 should be documented somewhere properly, so people can depend on it or not. IOBase.writelines handles generator arguments without problems, i.e. without first draining the entire generator and then writing the result in one go. That would require large amounts of memory if the generator is large, and fail entirely if the generator is infinite. codecs.StreamWriter.writelines uses self.write(''.join(argument)) as implementation, which fails on very large or infinite arguments. According to issue 5445 it is not part of the file protocol that .writelines must handle (large/infinite) generators, only list-like iterables. However as far as I know this is not documented anywhere, and sometimes people assume that writelines is meant for this case. E.g. jinja (https://github.com/mitsuhiko/jinja2/blob/master/jinja2/environment.py#L1153, the dump method is explicitly documented to stream). The guarantees that .writelines makes or does not make in this regard should be documented somewhere, so that either .writeline implementations that don't handle large generators can be pointed out as bugs, or code that makes assumptions on .writeline handling large generators can be. I personally think .writelines should handle large generators, since in the python 3 world a lot of apis were iterator-ified and it is wat a lot of people would probably expect. But having a clear and documented decision on this is more important. (note: I've copied most of the nosy list from #5445) ---------- assignee: docs@python components: Documentation, IO messages: 222165 nosy: JanKanis, benjamin.peterson, dlesco, docs@python, hynek, lemburg, pitrou, stutzbach, terry.reedy priority: normal severity: normal status: open title: File protocol should document if writelines must handle generators sensibly versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21910> _______________________________________

5 4

[issue24852] Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix
by John Hagen 07 Mar '16

07 Mar '16

New submission from John Hagen: https://docs.python.org/3.5/howto/webservers.html#setting-up-fastcgi The "HOWTO Use Python in the web" documentation for 3.5.0rc1 prescribes to use flup in its example, which is not compatible with Python 3. This has led to some confusion: https://stackoverflow.com/questions/23482357/fastcgi-wsgi-library-in-python… Perhaps the whole article could be given a once over to ensure it is still the best advice as of 2015. ---------- assignee: docs@python components: Documentation messages: 248491 nosy: John Hagen, docs@python priority: normal severity: normal status: open title: Python 3.5.0rc1 "HOWTO Use Python in the web" needs fix type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24852> _______________________________________

5 7

[issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools
by Jurko Gospodnetić 07 Mar '16

07 Mar '16

New submission from Jurko Gospodnetić: In the Python documentation note: http://docs.python.org/3.4/library/venv.html#venv-def the paragraph: > Common installation tools such as Distribute and pip work > as expected with venvs - i.e. when a venv is active, they > install Python packages into the venv without needing to > be told to do so explicitly. Of course, you need to > install them into the venv first: this could be done by > running distribute_setup.py with the venv activated, > followed by running easy_install pip. Alternatively, you > could download the source tarballs and run python setup.py > install after unpacking, with the venv activated. refers to the Distribute package and its specifics (how it should be installed) but that package has been deprecated in favor of the setuptools package. I suggest to change it to something like: > Common installation tools such as setuptools and pip work > as expected with venvs - i.e. when a venv is active, they > install Python packages into the venv without needing to > be told to do so explicitly. Of course, you need to > install them into the venv first: this could be done by > running setuptools project's ez_setup.py with the venv > activated, followed by running easy_install pip. > Alternatively, you could download the source tarballs and > run python setup.py install after unpacking, with the venv > activated. I'm attaching a patch based on the current tip in CPython's development repository. Hope this helps. Best regards, Jurko Gospodnetić ---------- assignee: docs@python components: Documentation files: fix_Distribute_reference_in_venv_docs.patch keywords: patch messages: 214554 nosy: Jurko.Gospodnetić, docs@python priority: normal severity: normal status: open title: Python docs reference the Distribute package which has been deprecated in favor of Setuptools versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34582/fix_Distribute_reference_in_venv_docs.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21034> _______________________________________

8 9

[issue22088] base64 module still ignores non-alphabet characters
by Julian Berman 24 Feb '16

24 Feb '16

New submission from Julian Berman: The base64 module documentation claims that decode methods raise exceptions for non-base64 input, but they do not. There was a patch for Py3 done in issue1466065, but the documentation was not updated for Py2. I have not read that ticket carefully enough to be able to tell what the expected resolution was for Py2 (fixing the bug or just updating the docs). ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 224089 nosy: Julian, docs@python, r.david.murray priority: normal severity: normal status: open title: base64 module still ignores non-alphabet characters type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22088> _______________________________________

4 6