docs May 2019

docs@python.org

17 participants
554 discussions

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

by Dan Snider

New submission from Dan Snider <mr.assume.away(a)gmail.com>: Unfortunately, it looks like there's no requirement for an abc.Sequence to implement the 3 argument form of seq.index, so I suppose this is technically just a documentation bug... >>> range(5).index(2, 1) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: index() takes exactly one argument (2 given) >>> help(range.index) Help on method_descriptor: index(...) rangeobject.index(value, [start, [stop]]) -> integer -- return index of value. Raise ValueError if the value is not present. ---------- assignee: docs@python components: Argument Clinic, Documentation messages: 326701 nosy: bup, docs@python, larry priority: normal severity: normal status: open title: range.index only takes one argument when it's documented as taking the usual 3 versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34848> _______________________________________

2 years, 8 months

[issue27409] List socket.SO_*, SCM_*, MSG_*, IPPROTO_* symbols

by Martin Panter

New submission from Martin Panter: The documentation just says that SO_* etc constants are defined. However when people add new ones, they add them as new features to a specific version (not backported as bug fixes), but do not alter the documentation at all. IMO it is silly adding undocumented features. E.g. Issue 26907 was opened to add (among others) SO_PASSCRED, which was already added, undocumented, as part of Issue 6560. This patch attempts to indicate which symbols are defined by Python (depending on OS availability), and therefore one can deduce if Python does not define a particular symbol. It could be adapted to the 2.7 documentation, but I am not really motivated for that on my own. I also remove a redundant definition in the module, and removed a conditional because SO_REUSEADDR is required to always be defined according to the test suite. These specific changes should only be applied to 3.6. I also found Issue 1732367, which has a patch documenting each AF_* symbol in a little more detail. That patch was never updated nor comitted, but it sounds like this kind of addition might be acceptable. ---------- assignee: docs@python components: Documentation files: socket-const.patch keywords: patch messages: 269460 nosy: docs@python, martin.panter priority: normal severity: normal stage: patch review status: open title: List socket.SO_*, SCM_*, MSG_*, IPPROTO_* symbols versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43573/socket-const.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27409> _______________________________________

2 years, 8 months

[issue36765] Invalid grammar for f_expression

by Kasra Vand

New submission from Kasra Vand <kasraavand(a)gmail.com>: Due to the discussion in following SO question https://stackoverflow.com/questions/55933956/what-does-a-star-asterisk-do-i… and the inconsistency of the source behaviour with the documentation I think using `"*" or_expr` for f_expression is wrong or at least not what it meant to be and very vague. I was wondering if there's any reason for using `"*" or_expr`. ---------- assignee: docs@python components: Documentation messages: 341186 nosy: Kasra Vand, docs@python priority: normal severity: normal status: open title: Invalid grammar for f_expression type: behavior versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36765> _______________________________________

2 years, 9 months

[issue36329] use the right python "make -C Doc/ serve"

by Berker Peksag

Berker Peksag <berker.peksag(a)gmail.com> added the comment: Personally, I'd prefer removing the 'serve' target completely. make -C Doc htmlview should already cover most of its use cases. There is no deprecation period needed and there is already a replacement (and IMO better) for it. ---------- nosy: +berker.peksag _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36329> _______________________________________

2 years, 9 months

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs May 2019