Mailman 3 October 2015 - docs

[issue25286] views are not sequences
by Akira Li Oct. 7, 2015

Oct. 7, 2015

New submission from Akira Li: The entry for *dict view* in the glossary may be clarified, to avoid confusion with collection.abc.Sequence i.e., from: They are lazy sequences that will see changes in the underlying dictionary. to something like: They provide a dynamic view on the dictionary’s entries, which means that when the dictionary changes, the view reflects these changes. See https://mail.python.org/pipermail/python-ideas/2015-October/036682.html I've attached the corresponding doc patch. ---------- assignee: docs@python components: Documentation files: dict-views-glossary.patch keywords: patch messages: 251995 nosy: akira, docs@python priority: normal severity: normal status: open title: views are not sequences type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40638/dict-views-glossary.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25286> _______________________________________

3 7

[issue25294] Absolute imports fail in some cases where relative imports would work
by Patrick Maupin Oct. 6, 2015

Oct. 6, 2015

New submission from Patrick Maupin: PEP 8 recommends absolute imports over relative imports, and section 5.4.2 of the import documentation says that an import will cause a binding to be placed in the imported module's parent's namespace. However, since (with all current Python versions) this binding is not made until _after_ the module body has been executed, there are cases where relative imports will work fine but absolute imports will fail. Consider the simple case of these five files: xyz.py: import x x/__init__.py: import x.y x/y/__init__.py: import x.y.a x/y/a/__init__.py: import x.y.b; foo = x.y.b.foo x/y/b/__init__.py: foo = 1 This will fail in a fashion that may be very surprising to the uninitiated. It will not fail on any of the import statements; rather it will fail with an AttributeError on the assignment statement in x.y.a, because the import of y has not yet finished, so y has not yet been bound into x. This could conceivably be fixed in the import machinery by performing the binding before performing the exec. Whether it can be done cleanly, so as not to cause compatibility issues with existing loaders, is a question for core maintainers. But if it is decided that the current behavior is acceptable, then at a minimum both the PEP 8 and the import documentation should have an explanation of this corner case and how it can be solved with relative imports. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 252078 nosy: Patrick Maupin, docs@python priority: normal severity: normal status: open title: Absolute imports fail in some cases where relative imports would work type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25294> _______________________________________

6 14

Suggestion for improving {} vs {:s} in Format Specification Mini-Language
by Horshack Horshack Oct. 5, 2015

Oct. 5, 2015

In the 3.x documentation for the format string specification https://docs.python.org/3/library/string.html#formatspec, the string representation table indicates that 's' and None are the same - {} vs {:s} for example. In practice the two are different with respect to how the argument is converted, which is especially important for objects that have no __format__ method defined. In 2.7x an object's __str__ method is called if there is no __format__ method, even if a format string like {:s} is specified. In 3.x if there is no __format__ method and any format string is specified, including just {:s}, a TypeError exception is thrown for a "non-empty format string passed to object.__format__". This difference may be documented elsewhere since it's not a format-string specific behavior pe-se but it would very helpful for those learning Python to reference this difference in the 3.x format string documentation as well, esp since the existing documentation's statement that the two are the same may be confusing to readers who see the different behavior between {} and {:s} on 2.7 vs 3.x, the latter causing an exception on 3.x Thanks, -adam <https://docs.python.org/3/library/string.html#formatspec>

1 0

[issue25175] Documentation-Tkinter wrong statement
by Rishit Bansal Oct. 5, 2015

Oct. 5, 2015

New submission from Rishit Bansal: The statement required to check whether Tkinter is installed on a system is mentioned in the documentation as python -m tkinter , whereas it is supposed to be python -m Tkinter (with a big 't'). Please correct this error on the documentation here:https://docs.python.org/3/library/tkinter.html as it is very misleading to beginners. ---------- assignee: docs@python components: Documentation messages: 251070 nosy: Rishit Bansal, docs@python priority: normal severity: normal status: open title: Documentation-Tkinter wrong statement type: compile error versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25175> _______________________________________

6 10

[issue22413] Bizarre StringIO(newline="\r\n") translation
by Guido van Rossum Oct. 5, 2015

Oct. 5, 2015

Guido van Rossum added the comment: It looks like we don't merge 2.7 into 3.4 any more, so that will have to be a separate patch anyway. So you can commit the patch to 3.4, merge into 3.5 and 3.6. Good luck! And thanks for your perseverance. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22413> _______________________________________

1 0

[issue22413] Bizarre StringIO(newline="\r\n") translation
by Guido van Rossum Oct. 5, 2015

Oct. 5, 2015

Guido van Rossum added the comment: The patch fails to apply in the 2.7 branch. It works in 3.4. Could you look into the 2.7 issue? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22413> _______________________________________

1 0

where is the chinese documents?
by wei zhang Oct. 5, 2015

Oct. 5, 2015

i'm new one. tks!

2 1

Tutorial 9.11. Generator Expressions Example
by Jonathan Klemm Oct. 4, 2015

Oct. 4, 2015

When I run the example here I get a NameError for the unique_words line page not defined and for valedictorian i get a NameError for graduates not defined. I am running python 3.4 on a Mac mini

1 0

[issue25238] Version added of context parameter for xmlrpc.client.ServerProxy incorrect
by R. David Murray Oct. 3, 2015

Oct. 3, 2015

R. David Murray added the comment: I agree with desbma, but would not consider it unreasonable to mention both versions in the 3.5+ docs in order to avoid any ambiguity. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25238> _______________________________________

1 0

[issue22413] Bizarre StringIO(newline="\r\n") translation
by Martin Panter Oct. 3, 2015

Oct. 3, 2015

Martin Panter added the comment: Here is a suggested patch. I did include details of the initializer and getvalue(); this is the heart of the problem IMO. In a limited sense the newline flag _is_ similar to TextIOWrapper, but more broadly this implied to me that newlines should be encoded in the buffer, just like in TextIOWrapper’s wrapped “buffer” and on disk. My patch also adds to a comment in the C code and removes another comment made out of date by Argument Clinic. In the documentation I didn’t mention the problem with split CRLFs; I think that is a separate bug. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> patch review status: closed -> open versions: +Python 2.7, Python 3.6 Added file: http://bugs.python.org/file40665/newline-doc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22413> _______________________________________

1 0