Mailman 3 February 2016 - docs

[issue26310] Fix typo “variariables” in socketserver.py
by Marien Feb. 8, 2016

Feb. 8, 2016

New submission from Marien: This patch fixes a typo in socketserver.py ---------- assignee: docs@python components: Documentation files: fix-typo-variariables.patch keywords: patch messages: 259869 nosy: docs@python, marienfr priority: normal severity: normal status: open title: Fix typo “variariables” in socketserver.py Added file: http://bugs.python.org/file41858/fix-typo-variariables.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26310> _______________________________________

3 3

Re: [docs] PEP 498 f-strings need to be documented (issue 25179)
by vadmium+py＠gmail.com Feb. 8, 2016

Feb. 8, 2016

https://bugs.python.org/review/25179/diff/16513/Doc/reference/lexical_analy… File Doc/reference/lexical_analysis.rst (right): https://bugs.python.org/review/25179/diff/16513/Doc/reference/lexical_analy… Doc/reference/lexical_analysis.rst:661: cannot be split between literals. On 2016/02/07 16:32:18, eric.smith wrote: > between -> across Done. https://bugs.python.org/review/25179/diff/16513/Doc/whatsnew/3.6.rst File Doc/whatsnew/3.6.rst (right): https://bugs.python.org/review/25179/diff/16513/Doc/whatsnew/3.6.rst#newcod… Doc/whatsnew/3.6.rst:95: >>> f"He said his name is {name!r}." On 2016/02/07 16:32:18, eric.smith wrote: > Many people will see this as their first example. As such, I'd delete the !r and > just have it be f"He said his name is {name}." > > I think !r would tend to scare people off. Done. https://bugs.python.org/review/25179/

1 0

Fix typo “variariables” in socketserver.py (issue 26310)
by francismb＠email.de Feb. 8, 2016

Feb. 8, 2016

https://bugs.python.org/review/26310/diff/16529/Lib/socketserver.py File Lib/socketserver.py (right): https://bugs.python.org/review/26310/diff/16529/Lib/socketserver.py#newcode… Lib/socketserver.py:674: can define arbitrary other instance variables. LGTM https://bugs.python.org/review/26310/

1 0

[issue26198] PyArg_ParseTuple with format "et#" and "es#" detects overflow by raising TypeError instead of ValueError
by Hrvoje Nikšić Feb. 8, 2016

Feb. 8, 2016

New submission from Hrvoje Nikšić: The documentation for the "es#" format (and the "et#" that derives from it) documents the possibility of providing an already allocated buffer. Buffer overflow is detected and handled as follows: "If the buffer is not large enough, a ValueError will be set." However, the actual behavior is to raise a TypeError. Inspecting the code in getargs.c reveals that convertsimple() handles buffer overflow by returning a formatted message to its caller, convertitem(). Calls to convertitem() that return an error call seterror() to set the error, and seterror() unconditionally sets the PyExc_TypeError. This is not a big issue in practice, and since the behavior is not new, it might be best to simply update the documentation to match the existing practice instead of changing the behavior and risking breaking working code. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 258905 nosy: docs@python, hniksic priority: normal severity: normal status: open title: PyArg_ParseTuple with format "et#" and "es#" detects overflow by raising TypeError instead of ValueError type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26198> _______________________________________

6 16

Fix “allows to <verb>” in documentation (issue 26304)
by eric＠trueblade.com Feb. 8, 2016

Feb. 8, 2016

Looks good, other than the one typo I found. http://bugs.python.org/review/26304/diff/16519/Misc/HISTORY File Misc/HISTORY (right): http://bugs.python.org/review/26304/diff/16519/Misc/HISTORY#newcode2237 Misc/HISTORY:2237: attribute which allows seting custom per-pickler reduction functions. Should be "setting". http://bugs.python.org/review/26304/

1 0

[issue20109] TestProgram is mentioned in the unittest docs but is not documented
by R. David Murray Feb. 8, 2016

Feb. 8, 2016

New submission from R. David Murray: IMO, TestProgram should either be made anonymous in the docs ('main returns an object that has a results attribute...') or its external API should be formally documented. If results is the only external API other than its init (which is documented as unittest.main), then I would suggest the former. In either case exactly what 'results' contains should be clarified. ---------- assignee: docs@python components: Documentation messages: 207178 nosy: docs@python, r.david.murray priority: normal severity: normal status: open title: TestProgram is mentioned in the unittest docs but is not documented versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20109> _______________________________________

4 3

[issue8810] TZ offset description is unclear in docs
by Alexander Belopolsky Feb. 7, 2016

Feb. 7, 2016

New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: >From <http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcof…>: """ tzinfo.utcoffset(self, dt) Return offset of local time from UTC, in minutes east of UTC. """ This suggests that the return value is an integer representing the number of minutes. It is later explained that in fact "the value returned must be a timedelta object specifying a whole number of minutes", but many users won't read past the first sentence. I suggest s/in minutes east of UTC/as a timedelta object/. I think "east of UTC" is redundant given the next sentence, "If local time is west of UTC, this should be negative", but that can also be reworded for clarity as "The offset for timezones west of UTC is negative, and for those east of UTC is positive." ---------- assignee: docs@python components: Documentation keywords: easy messages: 106371 nosy: belopolsky, docs@python priority: normal severity: normal status: open title: TZ offset description is unclear in docs versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8810> _______________________________________

6 19

[issue25226] "suffix" attribute not documented in logging.TimedRotatingFileHandler
by NobilisVir Feb. 7, 2016

Feb. 7, 2016

New submission from NobilisVir: The suffix attribute that controls the timestamp portion that gets appended to the file name is not documented (but it would be very useful to be). The documentation is here - https://docs.python.org/2/library/logging.handlers.html#timedrotatingfileha… I learned about this attribute from an SO answer after searching for a solution to how to control the file name (this answer - http://stackoverflow.com/a/338566/1006955). ---------- assignee: docs@python components: Documentation messages: 251503 nosy: NobilisVir, docs@python priority: normal severity: normal status: open title: "suffix" attribute not documented in logging.TimedRotatingFileHandler type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25226> _______________________________________

4 4

PEP 498 f-strings need to be documented (issue 25179)
by eric＠trueblade.com Feb. 7, 2016

Feb. 7, 2016

Reviewers: , Message: Thanks for taking this on! I have just a few nits, as noted. http://bugs.python.org/review/25179/diff/16513/Doc/reference/lexical_analys… File Doc/reference/lexical_analysis.rst (right): http://bugs.python.org/review/25179/diff/16513/Doc/reference/lexical_analys… Doc/reference/lexical_analysis.rst:661: cannot be split between literals. between -> across http://bugs.python.org/review/25179/diff/16513/Doc/whatsnew/3.6.rst File Doc/whatsnew/3.6.rst (right): http://bugs.python.org/review/25179/diff/16513/Doc/whatsnew/3.6.rst#newcode… Doc/whatsnew/3.6.rst:95: >>> f"He said his name is {name!r}." Many people will see this as their first example. As such, I'd delete the !r and just have it be f"He said his name is {name}." I think !r would tend to scare people off. Please review this at http://bugs.python.org/review/25179/ Affected files: Doc/faq/programming.rst Doc/library/datetime.rst Doc/library/enum.rst Doc/library/stdtypes.rst Doc/library/string.rst Doc/reference/datamodel.rst Doc/reference/lexical_analysis.rst Doc/tutorial/inputoutput.rst Doc/tutorial/introduction.rst Doc/whatsnew/3.6.rst

1 0

Issue with python function names
by david becker Feb. 7, 2016

Feb. 7, 2016

Hi, I have a query in using function names. Python allows users to write their own functions with built-in function names. Example: def print(): return "strange" print() -- Returns strange ++++++++++++++++++++++++++++ But the built in "print" function doesn't work any more till i restart the shell. I personally feel users should not be allowed to use built in function names. Is there any special reason why python allows them? Thanks, David Becker

2 2