Mailman 3 August 2013 - docs

[issue18688] Document undocumented Unicode object API
by Serhiy Storchaka 30 Apr '16

30 Apr '16

New submission from Serhiy Storchaka: Include/unicodeobject.h contains followed names which are declared as public but are not documented in Doc/c-api/unicode.rst. PyUnicodeIter_Type Py_UNICODE_REPLACEMENT_CHARACTER PyUnicode_Resize PyUnicode_InternImmortal PyUnicode_CHECK_INTERNED PyUnicode_FromOrdinal PyUnicode_GetDefaultEncoding PyUnicode_AsDecodedObject PyUnicode_AsDecodedUnicode PyUnicode_AsEncodedObject PyUnicode_AsEncodedUnicode PyUnicode_BuildEncodingMap PyUnicode_DecodeCodePageStateful PyUnicode_Append PyUnicode_AppendAndDel PyUnicode_Partition PyUnicode_RPartition PyUnicode_RSplit PyUnicode_IsIdentifier _PyUnicode_FromId _PyUnicode_ClearStaticStrings They should be either documented or declared as private. PyUnicode_AsEncodedObject only mentioned in Doc/whatsnew/3.3.rst as recomended replacement of PyUnicode_Encode. ---------- assignee: docs@python components: Documentation, Unicode messages: 194705 nosy: docs@python, ezio.melotti, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Document undocumented Unicode object API type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18688> _______________________________________

3 6

[issue18572] Remove redundant note about surrogates in string escape doc
by Steven D'Aprano 24 Apr '16

24 Apr '16

New submission from Steven D'Aprano: The documentation for string escapes suggests that \uxxxx escapes can be used to generate characters in the Supplementary Multilingual Planes by using surrogate pairs: "Individual code units which form parts of a surrogate pair can be encoded using this escape sequence." http://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-l… E.g. in Python 3.2: py> '\uD80C\uDC80' == '\U00013080' True but that is no longer the case in Python 3.3. I suggest the documentation should just remove that note. ---------- assignee: docs@python components: Documentation messages: 193787 nosy: docs@python, stevenjd priority: normal severity: normal status: open title: Remove redundant note about surrogates in string escape doc versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18572> _______________________________________

6 8

[issue18353] PyUnicode_WRITE_CHAR macro definition missing
by Wolf Ihlenfeldt 24 Apr '16

24 Apr '16

New submission from Wolf Ihlenfeldt: Above macro is mentioned in the documentation (3.3.2), but does not appear in the header files. Associated function PyUnicode_WriteChar() is present and works as expected. ---------- assignee: docs@python components: Documentation, Unicode messages: 192247 nosy: Wolf.Ihlenfeldt, docs@python, ezio.melotti priority: normal severity: normal status: open title: PyUnicode_WRITE_CHAR macro definition missing type: compile error versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18353> _______________________________________

6 5

[issue9014] Incorrect documentation of the PyObject_HEAD macro
by Renato Cunha 19 Apr '16

19 Apr '16

New submission from Renato Cunha <renato(a)renatocunha.com>: PyObject_HEAD's documentation in py3k (http://docs.python.org/dev/py3k/c-api/structures.html#PyObject_HEAD) uses the same content used in the python 2.x's docs which is wrong, as there were some API changes. PyObject_HEAD is actually defined as #define PyObject_HEAD PyObject ob_base; with PyObject defined as typedef struct _object { _PyObject_HEAD_EXTRA Py_ssize_t ob_refcnt; struct _typeobject *ob_type; } PyObject; (The PyTRACE_REFS discussion is still valid, though.) Additionally, it'd be nice to mention that the Py_REFCNT(ob) and Py_TYPE(ob) macros should be used to access the PyObject members. ---------- assignee: docs@python components: Documentation messages: 107953 nosy: docs@python, trovao priority: normal severity: normal status: open title: Incorrect documentation of the PyObject_HEAD macro type: behavior versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9014> _______________________________________

7 9

[issue15984] Wrong documentation for PyUnicode_FromObject()
by Serhiy Storchaka 15 Apr '16

15 Apr '16

New submission from Serhiy Storchaka: In the documentation it is written that PyUnicode_FromObject() is a shortcut for PyUnicode_FromEncodedObject(). But PyUnicode_FromObject() is not call PyUnicode_FromEncodedObject() direct nor indirect. PyUnicode_FromObject() works only with unicode and unicode subclass objects, PyUnicode_FromEncodedObject() is not works with unicode objects. ---------- assignee: docs@python components: Documentation messages: 170821 nosy: docs@python, storchaka priority: normal severity: normal status: open title: Wrong documentation for PyUnicode_FromObject() versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15984> _______________________________________

11 26

[issue14456] Relation between threads and signals unclear
by Sven Marnach 11 Apr '16

11 Apr '16

New submission from Sven Marnach <sven(a)marnach.net>: The documentation of the 'signal' module states on the one hand [T]he main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads). On the other hand, it provides the function 'pthread_kill()': Send the signal signum to the thread thread_id, another thread in the same process as the caller. The signal is asynchronously directed to thread. These two passages are in contradiction to each other. The documentation also states that only the main thread can set signal handlers -- if this is true, it is utterly unclear how sending signals to other threads is useful. Probably the documentation wasn't fully updated when the above function was introduced. ---------- assignee: docs@python components: Documentation messages: 157156 nosy: docs@python, smarnach priority: normal severity: normal status: open title: Relation between threads and signals unclear versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14456> _______________________________________

4 6

[issue10289] Document magic methods called by built-in functions
by Éric Araujo 10 Apr '16

10 Apr '16

New submission from Éric Araujo <merwok(a)netwok.org>: At the top of Doc/library/functions.rst, which documents built-in functions like abs, getattr or hash, a comment reads “document all delegations to __special__ methods”. Some functions are already good: enumerate for instance does link to the definition of iterator and hints about the __next__ method, format points to __format__, etc. They can serve as example for how to add links (in plain text and in the global index). ---------- assignee: docs@python components: Documentation messages: 120189 nosy: docs@python, eric.araujo priority: normal severity: normal stage: needs patch status: open title: Document magic methods called by built-in functions versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10289> _______________________________________

10 14

[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

[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