New submission from Adrian Chan:
I uninstalled python 2.7 and 3.4, then performed a fresh install of 3.5.3.
Running pip with `python -m pip` as per https://docs.python.org/3.5/installing gives the following error:
C:\Python\Python35-32\python.exe: No module named pip.__main__; 'pip' is a package and cannot be directly executed
Installation details:
* win 7 64 bit.
* python 3.5.3 32 bit.
* chose options for pip, tcl/tk/idle, test suite, py launcher, shortcuts, add to env, precompile std lib.
* installed to non-standard directory.
----------
assignee: docs@python
components: Documentation, Installation, Windows
messages: 287986
nosy: Adrian Chan, docs@python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot run pip in fresh install of py 3.5.3
type: behavior
versions: Python 3.5
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue29586>
_______________________________________
New submission from Nathan Marrow:
The documentation for emulating callable objects with __call__ seems to imply only positional arguments are supported. For instance, it says __call__ is "object.__call__(self[, args…])" and describes:
Called when the instance is “called” as a function; if this method is defined, x(arg1, arg2, ...) is a shorthand for x.__call__(arg1, arg2, ...).
When it should be something like (Not sure exactly what the syntax would be here):
"object.__call__(self[, args…] [,**kwargs...])"
Called when the instance is “called” as a function; if this method is defined, x(arg1, arg2, ..., arg3=arg3) is a shorthand for x.__call__(arg1, arg2, ..., arg3=arg3).
----------
assignee: docs@python
components: Documentation
messages: 302185
nosy: docs@python, nmarrow
priority: normal
severity: normal
status: open
title: "Emulating callable objects" documentation misleading
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue31472>
_______________________________________
New submission from ipatrol:
https://docs.python.org/3/reference/expressions.html#comparisons says that "Strings and binary sequences cannot be directly compared." That would seem to me to imply that an equality between them would raise an exception, as also claimed by https://wiki.python.org/moin/BytesStr
However, that is manifestly incorrect. Bytes and strings can be compared: they are always unequal. This appears to be a result of the operation falling through to the default comparison, which returns False since they are not identical objects. Equality is a comparison, though it is not an order comparison. A brief search of the word "cannot" in the documentation suggest that saying a certain thing cannot be done usually implies that attempting to do so anyway will raise an exception, typically a TypeError. That this is not the case for string-bytes comparisons should be mentioned.
----------
assignee: docs@python
components: Documentation
messages: 294200
nosy: docs@python, ipatrol
priority: normal
severity: normal
status: open
title: Documentation either unclear or incorrect on comparisons between bytes and strings in Python 3
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue30435>
_______________________________________
New submission from Marc Brünink:
The documentation for is not very clear regarding the usage of CDLL and PyDLL. Especially it is not obvious that you should use PyDLL whenever you call any function of the Python/C API. Since calling a Python/C API function without owning the GIL will most likely cause latent segfaults, I think it warrants a warning box in section 16.17.2.2 and maybe also somewhere prominent in http://docs.python.org/dev/c-api/intro.html.
For section 16.17.2.2 I would put a box next the decription of CDLL saying something like: "The Python GIL is released before a function call. It is not safe to call any Pyhon/C API function within the loaded library without acquiring the GIL first. Thus, if the loaded library calls functions of the Python/C API, for example in case it creates and returns a new Python object, and does not manually acquire and release the GIL, use PyDLL instead."
----------
assignee: docs@python
components: Documentation
messages: 189629
nosy: Marc.Brünink, docs@python
priority: normal
severity: normal
status: open
title: ctypes.PyDLL documentation
versions: Python 3.5
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue18017>
_______________________________________
New submission from Andrew Svetlov:
Hi.
On reading the doc for pathlib I've stuck with `.rename()` and `.replace()` (https://docs.python.org/3/library/pathlib.html#pathlib.Path.rename).
What's the difference?
Going to pathlib's source code I've figured out that methods are use different functions from `os` module: `os.rename()` and `os.replace()`.
But the documentation for `os` module is not obvious too:
the docs for both functions are almost equal from my perspective, the only significant difference is that `os.rename()` suggests to use `os.replace()` for cross-compatibility.
Could anybody explain the difference?
Also, at least the doc for `pathlib.Path.rename` worth to have a sentence like borrowed from `os.rename`: "If you want cross-platform overwriting of the destination, use replace()."
----------
assignee: docs@python
components: Documentation
keywords: easy
messages: 273836
nosy: asvetlov, docs@python, pitrou
priority: low
severity: normal
status: open
title: Docs: the difference between rename and replace is not obvious
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue27886>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________