[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 revoking unmaintained/unused packages, would be difficult to police fairly -- ___ Python tracker <https://bugs.python.org/issue40132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 there were some malicious users typo squatting famous package names (https://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/), now fixed, but I'm more referring to the more general issue. My guess is, if python continues to grow in popularity, it is only a matter of time before some unhelpful folks decide to reserve generic package names (common words etc.) and there is a market for selling PyPI package names (like the situation with domain names now). Personally, I'm not sure this would be good for the python community, but I don't know if there is (or could be) any solutions? -- messages: 365454 nosy: ChrisRands priority: normal severity: normal status: open title: Mechanism to control who owns package names on PyPI? ___ Python tracker <https://bugs.python.org/issue40132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 this explains the behaviour, but still seems odd to me? Relevant SO question: https://stackoverflow.com/questions/56633402/why-are-true-and-false-being-set-in-globals-by-this-code -- messages: 345863 nosy: ChrisRands priority: normal severity: normal status: open title: builtins.True exists but can't be accessed type: behavior ___ Python tracker <https://bugs.python.org/issue37318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue35526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 permanent without the __future__ import and cannot be switched off. In this case, this means the '!=' operator becomes a SynaxError, with obvious consequences for existing python code. Now of course this is just an Easter egg, but given that 3.9 is surely on the horizon now, isn't it time to modify the joke, or maybe I'm missing the point and the joke is on me? -- messages: 332068 nosy: ChrisRands priority: normal severity: normal status: open title: __future__.barry_as_FLUFL documented as mandatory for Python 3.9 ___ Python tracker <https://bugs.python.org/issue35526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue34764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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)
Is exactly equivalent to the following because an empty string is only returned
by readline at the EOF:
with open('mydata.txt') as fp:
for line in fp:
process_line(line)
The empty string '' sentinel value could be changed to another value to provide
a possibly more meaningful example where the 2nd code snippet would not always
produce the same result?
--
assignee: docs@python
components: Documentation
messages: 325995
nosy: ChrisRands, docs@python
priority: normal
severity: normal
status: open
title: Improve documentation example for using iter() with sentinel value
___
Python tracker
<https://bugs.python.org/issue34764>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8
ChrisRands added the comment: Ok thanks both for the clarification! -- ___ Python tracker <https://bugs.python.org/issue32830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8
ChrisRands 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-parentheses -- ___ Python tracker <https://bugs.python.org/issue32830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8
New submission from ChrisRands : 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 obviously contradicts PEP8: "Wildcard imports (from import *) should be avoided" https://www.python.org/dev/peps/pep-0008/#imports Is tkinter a valid exception or is this a documentation bug? The commit of this line to the documentation is >10 years old (at least Python 2.4 I think): https://github.com/python/cpython/commit/116aa62bf54a39697e25f21d6cf6799f7faa1349#diff-05a258c160de90c51c1948689f788ef7R53 -- assignee: docs@python components: Documentation messages: 312045 nosy: ChrisRands, docs@python priority: normal severity: normal status: open title: tkinter documentation suggests "from tkinter import *", contradicting PEP8 ___ Python tracker <https://bugs.python.org/issue32830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue29677> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the current behavior.
The docs are currently silent on this:
https://docs.python.org/3/library/functions.html#round
I don't know C, but there appears to be a note in the source about this
implying it is the desired behavior but without an explanation: "For ndigits <
NDIGITS_MIN, x always rounds to +-0.0.":
https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Objects/floatobject.c
Anyway, I can't imagine an actual use case for negative ndigits.
--
messages: 288710
nosy: ChrisRands
priority: normal
severity: normal
status: open
title: 'round()' accepts a negative integer for ndigits
___
Python tracker
<http://bugs.python.org/issue29677>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, in reality list.index can take further arguments: index(...) L.index(value, [start, [stop]]) -> integer -- return first index of value. Raises ValueError if the value is not present. -- assignee: docs@python components: Documentation messages: 279913 nosy: ChrisRands, docs@python priority: normal severity: normal status: open title: list.index documentation missing start and stop arguments ___ Python tracker <http://bugs.python.org/issue28587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
