Mailman 3 May 2016 - docs

[issue16272] C-API documentation clarification for tp_dictoffset
by Chris Colbert 05 Mar '21

05 Mar '21

New submission from Chris Colbert: The documentation of the tp_dictoffset is a bit unclear when describing the responsibilities of a base type with a nonzero tp_dictoffset. http://docs.python.org/c-api/typeobj.html I feel there should some statement to the effect of: """ If a type defines a nonzero tp_dictoffset, that type is responsible for defining a `__dict__` slot as part of the tp_getset structures. Failure to do so will result in the dict being inaccesible from Python via `obj.__dict__` from instances of the type or subtypes. """ The reasoning is twofold: 1) `PyType_Ready` does not add the default getset members like `type_new` does. This prevents the instances of the type itself from retrieving `obj.__dict__` 2) `type_new` will provide the default `subtype_dict` getset member for subclasses, but this calls `get_builtin_base_with_dict` which will resolve to the most base type which is not heap allocated; in this case, the C type. Since this type has no `__dict__` getset member, the lookup fails. Adding a bit of verbage about this "gotcha" would likely save some headaches in the future. ---------- assignee: docs@python components: Documentation messages: 173222 nosy: Chris.Colbert, docs@python priority: normal severity: normal status: open title: C-API documentation clarification for tp_dictoffset versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16272> _______________________________________

6 7

[issue12594] Docs for py3k still refer to "MacPython 2.5 folder"
by Christoph Schindler 04 Mar '21

04 Mar '21

New submission from Christoph Schindler <hop(a)30hopsmax.at>: In http://docs.python.org/py3k/using/mac.html#getting-and-installing-macpython and http://docs.python.org/py3k/using/mac.html#distributing-python-applications… . ---------- assignee: docs@python components: Documentation messages: 140744 nosy: docs@python, hop priority: normal severity: normal status: open title: Docs for py3k still refer to "MacPython 2.5 folder" versions: Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12594> _______________________________________

7 11

[issue24650] Error in yield expression documentation
by swanson 27 Feb '21

27 Feb '21

New submission from swanson: https://docs.python.org/3/reference/expressions.html in 6.2.9. Yield expressions end of 1st paragraph: "Using a yield expression in a function’s body causes that function to be a generator." NO! As the very next sentence explains, a generator is what's returned by such a function, not the function itself. Basically, it should be sufficient to add the word "function" to the end of that sentence: "... generator function." However, this error does NOT exist in 3.0 to 3.2 - just in 3.3 to 3.6, so I suggest just using the same wording as 3.0 to 3.2: "Using a yield expression in a function definition is sufficient to cause that definition to create a generator function instead of a normal function." ---------- assignee: docs@python components: Documentation messages: 246841 nosy: docs@python, swanson priority: normal severity: normal status: open title: Error in yield expression documentation versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24650> _______________________________________

4 4

[issue24045] Behavior of large returncodes (sys.exit(nn))
by Ethan Furman 26 Feb '21

26 Feb '21

New submission from Ethan Furman: Not sure if this is a bug, or just One of Those Things: sys.exit(large_value) can wrap around if the value is too large, but this is O/S dependent. linux (ubuntu 14.04) $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(256) $ echo $? 0 $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(257) $ echo $? 1 M$ (Windows 7) > python Python 2.7... --> import sys --> sys.exit(65535) > echo %errorlevel% 65535 > python Python 2.7... --> import sys --> sys.exit(100000) > echo %errorlevel% 100000 Perhaps a minor doc update that talks about return codes and why they might not be exactly what was given to Python? ---------- assignee: docs@python messages: 241903 nosy: docs@python, ethan.furman priority: normal severity: normal status: open title: Behavior of large returncodes (sys.exit(nn)) versions: Python 2.7, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24045> _______________________________________

4 5

[issue13368] Possible problem in documentation of module subprocess, method send_signal
by Eli Bendersky 24 Feb '21

24 Feb '21

New submission from Eli Bendersky <eliben(a)gmail.com>: docs@ list report by Daniel Dieterle: in the documentation (http://docs.python.org/library/subprocess.html#subprocess.Popen.send_signal) is a bug. CTRL_C_EVENT can not be sent to processes started with a creationflags parameter which includes CREATE_NEW_PROCESS_GROUP. Why can be read in the msdn documentation http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155%28v=vs.85%… . A workaround using CTRL_C_EVENT nevertheless is described here: http://stackoverflow.com/questions/7085604/sending-c-to-python-subprocess-o… -- I do not know why the subprocess.CREATE_NEW_PROCESS_GROUP parameter was introduced. But it is useless for terminating a process with os.kill() in combination with signal.SIGTERM, which corresponds to a CTRL-C-EVENT. A CTRL-C-EVENT is only forwarded to the process if the process group is zero. Therefore the Note in the documentation on Popen.send_signal() is wrong. ---------- assignee: docs@python components: Documentation messages: 147272 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Possible problem in documentation of module subprocess, method send_signal versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13368> _______________________________________

4 6

[issue16954] Add docstrings for ElementTree module
by Serhiy Storchaka 21 Feb '21

21 Feb '21

New submission from Serhiy Storchaka: Perhaps almost all Doxygen comments in ElementTree module should be converted to docstrings. ---------- assignee: docs@python components: Documentation, XML messages: 179881 nosy: docs@python, eli.bendersky, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add docstrings for ElementTree module type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16954> _______________________________________

8 23

[issue13433] String format documentation contains error regarding %g
by Christian Iversen 18 Feb '21

18 Feb '21

New submission from Christian Iversen <ci(a)sikkerhed.org>: The documentation for string format options state that both %f, %g and %e default to 6 digits after the decimal point. In fact, %g always seems to use 5 digits by default: >>> "%g" % 2.1234567 '2.12346' >>> "%f" % 2.1234567 '2.123457' >>> "%e" % 2.1234567 '2.123457e+00' But something much more insidious is wrong, because even when explicitly told how many digits to have, %g is one off: >>> "%.6g" % 2.1234567 '2.12346' >>> "%.6f" % 2.1234567 '2.123457' >>> "%.6e" % 2.1234567 '2.123457e+00' This can't be right? ---------- assignee: docs@python components: Documentation messages: 147940 nosy: Christian.Iversen, docs@python priority: normal severity: normal status: open title: String format documentation contains error regarding %g type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13433> _______________________________________

6 11

[issue20464] Update distutils sample config file in Doc/install/index.rst
by Zachary Ware 03 Feb '21

03 Feb '21

New submission from Zachary Ware: >From docs@: On Thu, Jan 16, 2014 at 2:56 AM, Peter Bröcker <peter.broecker(a)uni-koeln.de> wrote: > Hi, > > I have tried to set up the distutils config files for a custom module > installation. Using the suggested snippet from > > http://docs.python.org/2/install/ > > [install] > install-base=$HOME/python > install-purelib=lib > install-platlib=lib.$PLAT > install-scripts=scripts > install-data=data did not work for me. > > Instead, I had to add install-headers and additionally modify all paths > to include $base: > > [install] > install-base=/some/dir > install-purelib=$base/lib > install-platlib=$base/lib.$PLAT > install-scripts=$base/scripts > install-headers=$base/include > install-data=$base/data > > > I'm unsure if this is actually a bug, but I could only resolve this with > the help of this answer on stackoverflow: > http://stackoverflow.com/a/12768721 > > Best regards, > Peter ---------- assignee: docs@python components: Distutils, Documentation messages: 209829 nosy: docs@python, zach.ware priority: normal severity: normal stage: test needed status: open title: Update distutils sample config file in Doc/install/index.rst type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20464> _______________________________________

3 4

[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
by paul j3 27 Jan '21

27 Jan '21

New submission from paul j3: When there's a conflict involving an argument that was added via 'parents', and the conflict handler is 'resolve', the action in the parent parser may be damaged, rendering that parent unsuitable for further use. In this example, 2 parents have the same '--config' argument: parent1 = argparse.ArgumentParser(add_help=False) parent1.add_argument('--config') parent2 = argparse.ArgumentParser(add_help=False) parent2.add_argument('--config') parser = argparse.ArgumentParser(parents=[parent1,parent2], conflict_handler='resolve') The actions of the 3 parsers are (from the ._actions list): (id, dest, option_strings) parent1: [(3077384012L, 'config', [])] # empty option_strings parent2: [(3076863628L, 'config', ['--config'])] parser: [(3076864428L, 'help', ['-h', '--help']), (3076863628L, 'config', ['--config'])] # same id The 'config' Action from 'parent1' is first copied to 'parser' by reference (this is important). When 'config' from 'parent2' is copied, there's a conflict. '_handle_conflict_resolve()' attempts to remove the first Action, so it can add the second. But in the process it ends up deleting the 'option_strings' values from the original action. So now 'parent1' has an action in its 'optionals' argument group with an empty option_strings list. It would display as an 'optionals' but parse as a 'positionals'. 'parent1' can no longer be safely used as a parent for another (sub)parser, nor used as a parser itself. The same sort of thing would happen, if, as suggested in the documentation: "Sometimes (e.g. when using parents_) it may be useful to simply override any older arguments with the same option string." In test_argparse.py, 'resolve' is only tested once, with a simple case of two 'add_argument' statements. The 'parents' class tests a couple of cases of conflicting actions (for positionals and optionals), but does nothing with the 'resolve' handler. ------------------------------ Possible fixes: - change the documentation to warn against reusing such a parent parser - test the 'resolve' conflict handler more thoroughly - rewrite this conflict handler so it does not modify the action in the parent - possibly change the 'parents' mechanism so it does a deep copy of actions. References: http://stackoverflow.com/questions/25818651/argparse-conflict-resolver-for-… http://bugs.python.org/issue15271 argparse: repeatedly specifying the same argument ignores the previous ones http://bugs.python.org/issue19462 Add remove_argument() method to argparse.ArgumentParser http://bugs.python.org/issue15428 add "Name Collision" section to argparse docs ---------- assignee: docs@python components: Documentation, Library (Lib), Tests messages: 226862 nosy: docs@python, paul.j3 priority: normal severity: normal status: open title: argparse: 'resolve' conflict handler damages the actions of the parent parser type: behavior versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22401> _______________________________________

3 15

[issue24711] Document getpass.getpass behavior on ^C
by Markus Unterwaditzer 11 Jan '21

11 Jan '21

New submission from Markus Unterwaditzer: getpass.getpass doesn't enter a newline when the user aborts input with ^C, while input/raw_input does. This behavior is surprising and can lead to mis-formatting of subsequent output. However, since this behavior exists since 2.7 and applications may have started to rely on it, I'd add a note to the documentation. ---------- assignee: docs@python components: Documentation messages: 247302 nosy: docs@python, untitaker priority: normal severity: normal status: open title: Document getpass.getpass behavior on ^C 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/issue24711> _______________________________________

2 2