Mailman 3 April 2016 - docs

[issue14456] Relation between threads and signals unclear
by Sven Marnach April 11, 2016

April 11, 2016

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

Wrong documentation for PyUnicode_FromObject() (issue 15984)
by storchaka＠gmail.com April 10, 2016

April 10, 2016

Reviewers: , http://bugs.python.org/review/15984/diff/16922/Doc/c-api/unicode.rst File Doc/c-api/unicode.rst (right): http://bugs.python.org/review/15984/diff/16922/Doc/c-api/unicode.rst#newcod… Doc/c-api/unicode.rst:730: Copy a Unicode subtype object to a new base Unicode object if necessary. The term "base Unicode object" is not used anywhere else. The documentation for PyUnicode_Check() and PyUnicode_CheckExact() say just about a Unicode object and an instance of a Unicode subtype. Please review this at http://bugs.python.org/review/15984/ Affected files: Doc/c-api/unicode.rst Include/unicodeobject.h # HG changeset patch # Parent 4e186581fea7f82ce4688560e577d059eafccf01 diff -r 4e186581fea7 Doc/c-api/unicode.rst --- a/Doc/c-api/unicode.rst Wed May 01 00:17:45 2013 +0200 +++ b/Doc/c-api/unicode.rst Sun Apr 10 04:09:49 2016 +0000 @@ -727,8 +727,11 @@ .. c:function:: PyObject* PyUnicode_FromObject(PyObject *obj) - Shortcut for ``PyUnicode_FromEncodedObject(obj, NULL, "strict")`` which is used - throughout the interpreter whenever coercion to Unicode is needed. + Copy a Unicode subtype object to a new base Unicode object if necessary. + If *obj* is already a base Unicode object, return the reference with + incremented refcount. + + Objects other than Unicode or its subtypes will cause a :exc:`TypeError`. Locale Encoding diff -r 4e186581fea7 Include/unicodeobject.h --- a/Include/unicodeobject.h Wed May 01 00:17:45 2013 +0200 +++ b/Include/unicodeobject.h Sun Apr 10 04:09:49 2016 +0000 @@ -864,14 +864,11 @@ const char *errors /* error handling */ ); -/* Coerce obj to an Unicode object and return a reference with +/* Copy a Unicode subtype object to a new base Unicode object if necessary. + + If obj is already a base Unicode object, return the reference with *incremented* refcount. - Unicode objects are passed back as-is (subclasses are converted to - true Unicode objects), all other objects are delegated to - PyUnicode_FromEncodedObject(obj, NULL, "strict") which results in - using UTF-8 encoding as basis for decoding the object. - The API returns NULL in case of an error. The caller is responsible for decref'ing the returned objects.

1 0

[issue10289] Document magic methods called by built-in functions
by Éric Araujo April 10, 2016

April 10, 2016

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

[issue16679] Add advice about non-ASCII wsgiref PATH_INFO
by Martin Panter April 9, 2016

April 9, 2016

Changes by Martin Panter <vadmium+py(a)gmail.com>: ---------- title: Wrong URL path decoding -> Add advice about non-ASCII wsgiref PATH_INFO _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16679> _______________________________________

1 0

[issue17264] Update Building C and C++ Extensions with distutils documentation
by Berker Peksag April 9, 2016

April 9, 2016

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

Documentation: argparse's actions store_{true, false} default to False/True (undocumented) (issue 25314)
by vadmium+py＠gmail.com April 9, 2016

April 9, 2016

https://bugs.python.org/review/25314/diff/16913/Doc/library/argparse.rst File Doc/library/argparse.rst (right): https://bugs.python.org/review/25314/diff/16913/Doc/library/argparse.rst#ne… Doc/library/argparse.rst:924: keyword argument must be given. For other actions, is defaults to ``None``. Should be “it defaults to None” https://bugs.python.org/review/25314/

1 0

[issue18820] json.dump() ignores its 'default' option when serializing dictionary keys
by July Tikhonov April 8, 2016

April 8, 2016

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

[issue26703] Socket state corrupts when original socket object goes out of scope in a different thread
by Antoine Pitrou April 8, 2016

April 8, 2016

Antoine Pitrou added the comment: No need to apologize :) Perhaps we need to make the docs a bit clearer. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26703> _______________________________________

1 0

[issue26703] Socket state corrupts when original socket object goes out of scope in a different thread
by JoshN April 8, 2016

April 8, 2016

JoshN added the comment: Josh/Martin/Antoine: Thank you for the tips - I was not aware of the underlying mechanics, especially the separate abstraction layers. I did RTFM up and down before posting this, to be sure. My apologies for the inconvenience. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26703> _______________________________________

1 0

Possible typo in docs
by Andrew McFarland April 8, 2016

April 8, 2016

page in question: https://docs.python.org/2/library/heapq.html section: 8.4.2. Priority Queue Implementation Notes Currently: def remove_task(task): 'Mark an existing task as REMOVED. Raise KeyError if not found.' entry = entry_finder.pop(task) entry[-1] = REMOVED As it stands, 'task' is removed from dictionary 'entry_finder' and never replaced which is not the intention in my opinion. Possible fixes: 1.def remove_task(task): 'Mark an existing task as REMOVED. Raise KeyError if not found.' entry = entry_finder.pop(task) entry[-1] = REMOVED entry_finder[task] = entry 2.def remove_task(task): 'Mark an existing task as REMOVED. Raise KeyError if not found.' entry_finder[task][-1] = REMOVED Sincerely,AM

2 2