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 Windson Yang <wiwindson(a)gmail.com>:
I found other languages like Java and C++ have the method to access the first value in Queue like first() and peek(). Since we use deque_ to create Queue now, it's easy to implement in python using the index. Otherwise, we can add this to the document? I also found some discussion_ here.
.. _deque:
https://github.com/python/cpython/blob/master/Lib/queue.py#L205
.. _discussion https://mail.python.org/pipermail/python-list/2010-March/569930.html
----------
assignee: docs@python
components: Documentation
messages: 328963
nosy: Windson Yang, docs@python
priority: normal
severity: normal
status: open
title: Add peek() or first() method in queue
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue35118>
_______________________________________
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 Frank Griswold <py.griswolf(a)spamgourmet.com>:
This chunk of docs has bad info in both Python2 and Python3 docs:
4.1.3. Configuration
Python on OS X honors all standard Unix environment variables such as PYTHONPATH, but setting these variables for programs started from the Finder is non-standard as the Finder does not read your .profile or .cshrc at startup. You need to create a file ~/.MacOSX/environment.plist. See Apple’s Technical Document QA1067 for details.
If you search for QA1067, you are informed that the document is legacy and unsupported, with a suggestion for where to look now. That suggested link leads to a 404.
Searching the apple site, I find that at least some thoughtful developers think that configuring the environment isn't even possible, generally; and isn't considered good form even if so. Here:
https://forums.developer.apple.com/message/217422
I have no problem setting things for my terminal, as a longtime (unix) user, but for others, this section probably needs a complete examination with an eye toward making it current. quite possibly by reorganizing it.
----------
assignee: docs@python
components: Documentation
messages: 312023
nosy: docs@python, griswolf
priority: normal
severity: normal
status: open
title: Docs: Using Python on a Macintosh has bad info per Apple site
type: enhancement
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue32824>
_______________________________________
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>
_______________________________________