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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
New submission from Terry J. Reedy:
https://docs.python.org/3/reference/expressions.html#yield-expressions says
"When yield from <expr> is used, it treats the supplied expression
as a subiterator. All values produced by that subiterator ...".
To me "treats..expression as a subiterator" means that the expression must *be* an iterator, such as returned by iter or calling a generator function. Hence I was surprised upon reading "yield from <non-iterator iterable>" in stdlib code.
I confirmed that this usage is correct by trying
>>> def g():
yield from (1,2)
>>> i = g()
>>> next(i), next(i)
(1, 2)
and then reading the PEP380 Formal Semantics, which begins with "_i = iter(EXPR)". Hence I suggest the following replacement for the quote above:
"When yield from <expr> is used, the expression must be an iterable.
A subiterator is obtained with iter(<expr>). All values produced
by that subiterator ...".
Note that 'subiterator' is spelled in the following sentences 'underlying iterable' (which I am not sure I like) and 'sub-iterator' (and 'sub-generator'). I think we should be consistent for at least the two short 'yield from' paragraphs.
----------
assignee: docs@python
components: Documentation
messages: 271577
nosy: docs@python, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: yield from expression can be any iterable
type: behavior
versions: Python 3.5, Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue27646>
_______________________________________
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>
_______________________________________
New submission from Serhiy Storchaka:
>From the documentation:
https://docs.python.org/3/c-api/stable.html
In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API."
But they don't.
Following sample patch adds the notes to Unicode Objects and Codecs C API. I'm going to add them to all C API.
What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it?
----------
assignee: docs@python
components: Documentation
files: unicode-not-part-of-the-limited-api.patch
keywords: patch
messages: 284125
nosy: docs@python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document C API that is not part of the limited API
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46057/unicode-not-part-of-the-limited-api.patch
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue29086>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
New submission from Julian <python_org(a)somethinkodd.com>:
Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default.
What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range.
This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable.
>From an inspection of the manuals, Python 3.0.1 suffers from the same problem except, the names have changed. urllib.response sits on http.client.
I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap.
While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time.
----------
assignee: docs@python
components: Documentation, Library (Lib)
messages: 104763
nosy: docs@python, oddthinking
priority: normal
severity: normal
status: open
title: Unexpected default timeout in http-client-related libraries
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8595>
_______________________________________