Mailman 3 August 2013 - docs

[issue18627] Typo in Modules/hashlib.h
by Vajrasky Kok 02 Aug '13

02 Aug '13

New submission from Vajrasky Kok: Got typo in Modules/hashlib.h. See this patch for detail: --- a/Modules/hashlib.h Wed Jul 31 20:48:26 2013 -0400 +++ b/Modules/hashlib.h Fri Aug 02 12:39:00 2013 +0800 @@ -2,7 +2,7 @@ /* * Given a PyObject* obj, fill in the Py_buffer* viewp with the result - * of PyObject_GetBuffer. Sets and exception and issues a return NULL + * of PyObject_GetBuffer. Sets an exception and issues a return NULL * on any errors. */ #define GET_BUFFER_VIEW_OR_ERROUT(obj, viewp) do { \ ---------- assignee: docs@python components: Documentation messages: 194151 nosy: docs@python, vajrasky priority: normal severity: normal status: open title: Typo in Modules/hashlib.h versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18627> _______________________________________

3 2

[issue17145] memoryview(array.array)
by Demian Brecht 02 Aug '13

02 Aug '13

Demian Brecht added the comment: Bump. If the patch (or request) is invalid, might be worthwhile closing this issue (although I still think it's valid ;)). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17145> _______________________________________

1 0

[issue14956] custom PYTHONPATH may break apps embedding Python
by Kevin Harms 01 Aug '13

01 Aug '13

Kevin Harms added the comment: As far as I can tell, this issue is not resolved. It would be very nice for the C API to have the equivalent for -E for security reasons. I would like to make a setgid binary and do not want users to be able to set PYTHON* variables to force loading of custom code. ---------- nosy: +Kevin.Harms _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14956> _______________________________________

1 0

[issue18558] Iterable glossary entry needs clarification
by R. David Murray 01 Aug '13

01 Aug '13

R. David Murray added the comment: “What is the proper way of asking if an object is iterable if it does not support the iterator protocol but does support the old getitem protocol?” The *only* answer to that question is to try to iterate it, and see if you get a KeyError on "0". Since this results in obtaining the first element if it *is* iterable, and in the general case you cannot "reset" an iterable, there is no way to look before you leap. You have to catch the error after it occurs. This question and answer probably do belong on Stack Overflow or python-list, but the glossary entry still needs improvement, since the Iterable docs reference it :) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

[issue18558] Iterable glossary entry needs clarification
by Stephen Paul Chappell 01 Aug '13

01 Aug '13

Stephen Paul Chappell added the comment: Maybe this would have been more appropriate as a question on StackOverflow: What is the proper way of asking if an object is iterable if it does not support the iterator protocol but does support the old getitem protocol? One might argue that it is better to ask for forgiveness rather than permission, but that does not really answer the question. My impression of collections.abc.Iterable is that programmers can use it to ask if an object is iterable. Some argue that it is better to ask for forgiveness rather that permission and would suggest pretending that an object is iterable until it is proven otherwise. However, what do we use collections.abc.Iterable’s for then? The true question is really, “What is the proper way of asking if an object is iterable if it does not support the iterator protocol but does support the old getitem protocol?” More generically, how can you ask an object if it supports ANY iteration protocol? The query probably should have been posted on StackOverflow and not here. This may not be a problem with collections.abc.Iterable, and thus the issue should be closed. However, the previous question remains, and it is apparent that it cannot be answered with the abstract class as it currently is. Maybe the solution is to just ask for forgiveness where appropriate. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

[issue18558] Iterable glossary entry needs clarification
by R. David Murray 01 Aug '13

01 Aug '13

R. David Murray added the comment: That would give you a false positive, though. It would return True for the 'y' in my example, which is not iterable. So Iterable's behavior here is an example of the Python design rule "resist the temptation to guess". As Terry said, new classes should implement an __iter__ method. The __getitem__ iteration support is for backward compatibility. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

[issue18589] cross-referencing doesn't work between the extending guide and c-api
by Antoine Pitrou 01 Aug '13

01 Aug '13

New submission from Antoine Pitrou: It doesn't seem possible to make reference links to e.g. the definition for tp_clear. Both :attr:`tp_clear` and :attr:`PyTypeObject.tp_clear` do not make any link. The extending guide is littered with such broken references. ---------- assignee: docs@python components: Documentation messages: 193887 nosy: docs@python, eric.araujo, ezio.melotti, georg.brandl, pitrou priority: high severity: normal status: open title: cross-referencing doesn't work between the extending guide and c-api type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18589> _______________________________________

2 5

[issue18558] Iterable glossary entry needs clarification
by Stephen Paul Chappell 01 Aug '13

01 Aug '13

Stephen Paul Chappell added the comment: If my program needed to know if an object is iterable, it would be tempting to define and call the following function instead of using collections.abc.Iterable: def iterable(obj): try: iter(obj) except TypeError: return False return True Something tells me that is not what the author of collections.abc.Iterable intended. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18558> _______________________________________

1 0

[issue10434] Document the rules for "public names"
by Alexander Belopolsky 01 Aug '13

01 Aug '13

New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: As discussed in "Breaking undocumented API" thread [1] on python-dev, a definition of "public names" is buried deep in the language reference manual: """ The public names defined by a module are determined by checking the module’s namespace for a variable named __all__; if defined, it must be a sequence of strings which are names defined or imported by that module. The names given in __all__ are all considered public and are required to exist. If __all__ is not defined, the set of public names includes all names found in the module’s namespace which do not begin with an underscore character ('_'). __all__ should contain the entire public API. It is intended to avoid accidentally exporting items that are not part of the API (such as library modules which were imported and used within the module). """ [2] It has been argued that this is not the authoritative definition and alternatives have been suggested such as "any name that does not begin with an underscore except imported modules." mportant for the users and developers of cpython and other python implementations to know what names they can rely upon to stay defined between releases, the rules for "public names" should be documented. I agree that the library manual is a more appropriate place for such documentation. The definition should include the naming conventions and the set of promises that Python makes about public name availability in the future releases. [1] http://mail.python.org/pipermail/python-dev/2010-November/105490.html [2] http://docs.python.org/reference/simple_stmts.html ---------- assignee: docs@python components: Documentation messages: 121297 nosy: belopolsky, docs@python priority: normal severity: normal stage: needs patch status: open title: Document the rules for "public names" versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10434> _______________________________________

6 7