New submission from Giampaolo Rodola':
Also SEM_FAILCRITICALERRORS and other SEM_constants. They should as setting error mode on Windows for console applications is a pretty common use case (in fact ./Lib/test/libregrtest/setup.py uses it).
----------
assignee: docs@python
components: Documentation
messages: 293189
nosy: docs@python, giampaolo.rodola
priority: normal
severity: normal
status: open
title: msvcrt SetErrorMode not documented
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue30295>
_______________________________________
New submission from Dave Abrahams <dave(a)boostpro.com>:
On POSIX systems, the PATH environment variable is always used to
look up directory-less executable names passed as the first argument to Popen(...), but on Windows, PATH is only considered when shell=True is also passed.
Actually I think it may be slightly weirder than that when
shell=False, because the following holds for me:
C:\>rem ##### Prepare minimal PATH #####
C:\>set "PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem"
C:\>rem ##### Prepare a minimal, clean environment #####
C:\>virtualenv --no-site-packages e:\zzz
New python executable in e:\zzz\Scripts\python.exe
Installing setuptools................done.
C:\>rem ##### Show that shell=True makes the difference in determining whether PATH is respected #####
C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'])
<subprocess.Popen object at 0x0000000001DBE080>
>>> C:\Python26\python.exe
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'})
<subprocess.Popen object at 0x0000000001F05A90>
>>> C:\Python26\python.exe
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}, shell=True)
<subprocess.Popen object at 0x0000000001F05B00>
>>> e:\zzz\Scripts\python.exe
That is, it looks like the environment at the time Python is invoked is what counts unless I pass shell=True. I don't even seem to be able to override this behavior by changing os.environ: you can clear() it and pass env={} and subprocess.Popen(['python']) still succeeds.
This is a very important problem for portable code and one that took me hours to suss out. I think:
a) the current behavior needs to be documented
b) it needs to be fixed if possible
c) otherwise, shell=True should be the default
----------
assignee: docs@python
components: Documentation
messages: 104422
nosy: dabrahams, docs@python
priority: normal
severity: normal
status: open
title: subprocess portability issue
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________
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>
_______________________________________
New submission from Steve Barnes:
When running under pythonw, or pyinstaller with the -w flag, modules that use subprocess calls such as popen, run, etc. will crash if the default `stdout=None, stderr=None` behaviour is used rather than PIPE. This is an obscure problem which is very hard to debug yet there is no warning in the documentation on this.
I would like to suggest adding a :warning:`stdout=None, stderr=None` must not be used in any of the calls in this module when running under pythonw due to the lack of sys.stdout & sys.stderr in that case. Please use `stdout=PIPE, stderr=PIPE` instead.
A patch against the default branch would be:
diff -r 4243df51fe43 Doc/library/subprocess.rst
--- a/Doc/library/subprocess.rst Fri Feb 10 14:19:36 2017 +0100
+++ b/Doc/library/subprocess.rst Thu Mar 16 16:56:24 2017 +0000
@@ -33,6 +33,13 @@
function for all use cases it can handle. For more advanced use cases, the
underlying :class:`Popen` interface can be used directly.
+.. warning:: Do not use default parameters on Windows with pythonw.
+
+ As pythonw deletes `sys.stdout` & `sys.stderr` the use of the default
+ parameters, `stdout=None, stderr=None,`, which defaults to being
+ `stdout=sys.stdout, stderr=sys.stderr,` may cause unexpected crashes
+ it is recommended to use `stdout=PIPE, stderr=PIPE,` instead.
+
The :func:`run` function was added in Python 3.5; if you need to retain
compatibility with older versions, see the :ref:`call-function-trio` section.
----------
assignee: docs@python
components: Documentation
messages: 289722
nosy: Steve Barnes, docs@python
priority: normal
severity: normal
status: open
title: Documentation lacks clear warning of subprocess issue with pythonw
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue29829>
_______________________________________
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>
_______________________________________
New submission from Xiang Zhang:
https://docs.python.org/3.7/c-api/exceptions.html#c.PyErr_SetFromWindowsErr… it stills refers to PyErr_SetFromWindowsErrWithFilenameObject but this function doesn't exist since Py3.4. I didn't find when and why it's deleted.
And https://docs.python.org/3.4/c-api/exceptions.html#c.PyErr_SetFromWindowsErr raises OSError instead of WindowsError.
----------
assignee: docs@python
components: Documentation
messages: 283814
nosy: docs@python, xiang.zhang
priority: normal
severity: normal
status: open
title: Outdated C api doc about Windows error
versions: Python 3.5, Python 3.6, Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue29045>
_______________________________________
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>
_______________________________________