[issue29677] 'round()' accepts a negative integer for ndigits

ChrisRands added the comment: Ah yes, you're both completely right of course. Perhaps the docs could still be clarified though. I managed to completely overlook this, and perhaps other non-expert Python users would too. -- ___ Python tracker <

[issue29677] 'round()' accepts a negative integer for ndigits

New submission from ChrisRands: With a negative integer for ndigits the output from 'round()', for example 'round(3, -2)', is always zero ('0' for 'int.__round__' and '0.0' or '-0.0' for 'float.__round__'). I think either it should raise an exception or the docs should be updated to reflect

[issue28587] list.index documentation missing start and stop arguments

New submission from ChrisRands: In Python 3 and 2 docs https://docs.python.org/3.5/tutorial/datastructures.html, list.index only mentions the first argument: list.index(x) Return the index in the list of the first item whose value is x. It is an error if there is no such item. However

[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8

New submission from ChrisRands <chrisran...@gmail.com>: Issue arose from this SO post: https://stackoverflow.com/questions/48746351/documentation-is-contradicting-pep8 The tkinter documentation suggests: from tkinter import * https://docs.python.org/3/library/tkinter.html But this obv

[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8

ChrisRands <chrisran...@gmail.com> added the comment: Ok thanks both for the clarification! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8

ChrisRands <chrisran...@gmail.com> added the comment: Thanks Serhiy, you might be right (I am not a tkinter user myself). I also forgot to say that in PEP 328 tkinter is mentioned in this context: https://www.python.org/dev/peps/pep-0328/#rationale-for-paren

[issue34764] Improve documentation example for using iter() with sentinel value

ChrisRands added the comment: Thank you Raymond, I like both your examples, although I think I prefer 1) for the simplicity -- ___ Python tracker <https://bugs.python.org/issue34

[issue34764] Improve documentation example for using iter() with sentinel value

New submission from ChrisRands : This arose from this SO question: https://stackoverflow.com/questions/52446415/line-in-iterfp-readline-rather-than-line-in-fp The example given in the docs: with open('mydata.txt') as fp: for line in iter(fp.readline, ''): process_line(line

[issue35526] __future__.barry_as_FLUFL documented as mandatory for Python 3.9

ChrisRands added the comment: SO question where this derived from: https://stackoverflow.com/questions/53830960/can-all-future-statements-be-removed-from-a-python-code-without-affecting-i -- ___ Python tracker <https://bugs.python.org/issue35

[issue35526] __future__.barry_as_FLUFL documented as mandatory for Python 3.9

New submission from ChrisRands : A festive bug report: >>> from __future__ import barry_as_FLUFL >>> barry_as_FLUFL.mandatory (3, 9, 0, 'alpha', 0) So barry_as_FLUFL is documented to become mandatory for Python 3.9. Note that mandatory here means that the feature becomes

[issue34764] Improve documentation example for using iter() with sentinel value

Change by ChrisRands : -- keywords: +patch pull_requests: +10457 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34764> ___ ___ Py

[issue37318] builtins.True exists but can't be accessed

New submission from ChrisRands : On Python 3: >>> import builtins >>> 'True' in dir(builtins) True >>> builtins.True File "", line 1 builtins.True ^ SyntaxError: invalid syntax >>> So "True" is a keyword, I guess

[issue40132] Mechanism to control who owns package names on PyPI?

New submission from ChrisRands : Not sure if this is the right place to mention this (apologies if not). Naturally, package names are unique so when you run `pip install package-name` there is no ambiguity. However, this means that package names are limited and potentially valuable. Already

[issue40132] Mechanism to control who owns package names on PyPI?

ChrisRands added the comment: Thanks Rémi, I missed that in PEP 541. I am still concerned that PyPI may become saturated with unmaintained packages (it is already common that one's preferred package name is taken). However, the guidance is already clear, and I guess anything stronger, like