docs March 2018

docs@python.org

29 participants
575 discussions

[issue25741] Usual Installation Directory

by Firat Ozgul

New submission from Firat Ozgul: Official documentation reads: "On Windows machines, the Python installation is usually placed in C:\Python35" However, as of Python 3.5.0, usual installation directory on Windows is %LOCALAPPDATA%\Programs\Python. ---------- assignee: docs@python components: Documentation messages: 255455 nosy: docs@python, firatozgul priority: normal severity: normal status: open title: Usual Installation Directory type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25741> _______________________________________

6 months, 2 weeks

[issue31427] Proposed addition to Windows FAQ

by Stephan Houben

New submission from Stephan Houben: Several people have asked on python-list why they are running into these errors. Python 3.6.0 can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing. The solution is to install KB 2999226 "Update for Universal C Runtime in Windows". https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-run… Propose to add this as a Windows FAQ. ---------- assignee: docs@python components: Documentation messages: 301952 nosy: Stephan Houben, docs@python priority: normal severity: normal status: open title: Proposed addition to Windows FAQ type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31427> _______________________________________

6 months, 2 weeks

[issue15097] Improving wording on the thread-safeness of import

by Merlijn van Deen

New submission from Merlijn van Deen <valhallasw(a)gmail.com>: http://docs.python.org/library/threading.html#importing-in-threaded-code Currently, the documentation states "Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module." which, I think, fails to make the main point: a call to import acquires the import lock. A call to import from a second thread will thus block. As such, I would suggest rephrasing it to something like: "Firstly, an import acquires the import lock for that thread. Therefore, the import should not have the side effect of waiting for a different thread in any way, as this can lead to a deadlock if that thread directly or indirectly attempts to import a module." There are two additional points that might be interesting to note: (1) Any module can be imported. If the import causes a deadlock, that is a bad thing. Every module *will* be imported by tools such as nosetests. (1b) so: never, ever, have code that causes locks in a different thread in module level code witout 'if __name__=="__main__" ' blocks? (2) The lock is also acquired if a module has already been imported. For instance, in import sys # (1) def f(): import sys # (2) the import lock is acquired in (1) /and/ (2). Adding example code and/or a flow diagram might be a bit too much, but it does clarify how easy it is to make this mistake. See the attached for an example (both a simple example script, as well as a flow diagram explaining what happens). ---------- assignee: docs@python components: Documentation files: deadlock.py messages: 163068 nosy: docs@python, valhallasw priority: normal severity: normal status: open title: Improving wording on the thread-safeness of import type: enhancement Added file: http://bugs.python.org/file26037/deadlock.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________

6 months, 2 weeks

[issue30295] msvcrt SetErrorMode not documented

by Giampaolo Rodola'

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> _______________________________________

6 months, 2 weeks

[issue8557] subprocess portability issue

by Dave Abrahams

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> _______________________________________

6 months, 3 weeks

[issue16272] C-API documentation clarification for tp_dictoffset

by Chris Colbert

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 months, 3 weeks

[issue29829] Documentation lacks clear warning of subprocess issue with pythonw

by Steve Barnes

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> _______________________________________

6 months, 3 weeks

[issue12594] Docs for py3k still refer to "MacPython 2.5 folder"

by Christoph Schindler

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> _______________________________________

6 months, 3 weeks

[issue24650] Error in yield expression documentation

by swanson

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> _______________________________________

6 months, 3 weeks

[issue29045] Outdated C api doc about Windows error

by Xiang Zhang

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> _______________________________________

6 months, 4 weeks

← Newer
1
2
3
4
5
6
7
...
58
Older →

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs March 2018