[issue31042] Inconsistency in documentation of operator.index
Joseph Fox-Rabinovitz added the comment: I closed the issue (it's already been rejected), primarily based on > a.__index__ = is an unauthorized use of a *reserved* word and the > effect of such usage is not and need not be documented. > The entry for __*__ does include "*Any* use of __*__ names, in any context, > that does not follow explicitly documented use, is subject to breakage > without warning." To me, that says that the effect of the reserved-word > assignment is undefined. It could be made to raise an exception. It's like filing a bug report for UB in C. -- stage: needs patch -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of ctypes.CDLL does not correspond to code
Joseph Fox-Rabinovitz added the comment:
Last attempt before I give up:
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but not
when `winmode=None`. To reproduce, any combination of adding the folder
containing the DLL via `os.eviron['PATH'] += os.pathsep + ...`,
`os.add_dll_directory(...)`, `sys.path.append(...)` does not change the
behavior.
Worked prior to 3.8 because there was no `winmode` parameter, `mode` was passed
in diretly, and `ctypes.DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.
Discovery triggered by https://stackoverflow.com/q/59330863/2988730.
Some info summarized in https://stackoverflow.com/a/64472088/2988730.
Link to docs: https://docs.python.org/3.{8,9,10}/library/ctypes.html#ctypes.CDLL
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340
--
___
Python tracker
<https://bugs.python.org/issue42114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of ctypes.CDLL does not correspond to code
Joseph Fox-Rabinovitz added the comment:
Company firewall mutilated the text. Here is another attempt:
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but not
when `winmode=None`. To reproduce, any combination of adding the folder
containing the DLL via `os.eviron['PATH'] += os.pathsep + ...`,
`os.add_dll_directory(...)`, `sys.path.append(...)` does not change the
behavior.
Worked prior to 3.8 because there was no `parameter, and `mode` was passed in
direcCompany firewall mutilated the text. Here is another attempt:
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but not
when `winmode=None`. To reproduce, any combination of adding the folder
containing the DLL via `os.eviron['PATH'] += os.pathsep + ...`,
`os.add_dll_directory(...)`, `sys.path.append(...)` does not change the
behavior.
Worked prior to 3.8 because there was no `winmode` parameter, `mode` was passed
in diretly, and `ctypes.DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.
Discovery triggered by https://stackoverflow.com/q/59330863/2988730.
Some info summarized in https://stackoverflow.com/a/64472088/2988730.
yink to docs: https://docs.python.org/3.{8,9,10}/library/ctypes.html#ctypes.CDLL
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340t.ly,
`ctyp. .DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.
Discovery triggered by https://stackoverflow.com/q/59330863/2988730.
Some info summarized in https://stackoverflow.com/a/64472088/2988730.
yink to docs: https://docs.python.org/3.{8,9,10}/library/ctypes.html#ctypes.CDLL
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340
--
___
Python tracker
<https://bugs.python.org/issue42114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of ctypes.CDLL does not correspond to code
Change by Joseph Fox-Rabinovitz : -- title: Documentation of -> Documentation of ctypes.CDLL does not correspond to code ___ Python tracker <https://bugs.python.org/issue42114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of
New submission from Joseph Fox-Rabinovitz :
ctypes.CDLL initializer defined in version 3.8 and beyond as
```
def __init__(self, name, mode=DEFAULT_MODE, handle=None,
use_errno=False,
use_last_error=False,
winmode=None):
```
Documentation says `winmode=0`:
```
class ctypes.CDLL(name, mode=DEFAULT_MODE, handle=None, use_errno=False,
use_last_error=False, winmode=0)
```
Loading of normal DLL from custom directory works when `winmode=0`, but when
`winmode=None` To reproduce, any combination of adding the fol += der
containing the DLL to `os.evia ron['PATH']`, `os.add_dll_directory(...)`
Discoveryos.pathsep + ... triggered by https://stackoverflow.co, `sys.path.appen
Worked prior to 3.8 because there was no `winmode` parameter, and d(...)` does
not change the behavior.m/q/`mode` was passed in directly,
59330863/298873`ctypes0. .DEFAULT_MODE == 0`.
I don't know whether it's better to update the code, the docs, or something
else, but based on current info, would prefer updating the code.Some info
summarized in https://stackoverflow.com/a/{8,9,}64472088/2988730.
Link to do pagecscorresponding :
https://docs.python.org/3.10/library/ctypes.html#ctypes.CDLL
730.
Link to GitHub code:
https://github.com/python/cpython/blob/3.{8,9}/Lib/ctypes/__init__.py#L340
--
components: ctypes
messages: 379261
nosy: madphysicist
priority: normal
severity: normal
status: open
title: Documentation of
versions: Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
Joseph Fox-Rabinovitz added the comment: I brought up the issue because it was really a point of confusion for me. Could we make the change to "Roughly equivalent" and make that a link to https://docs.python.org/3/reference/datamodel.html#special-method-lookup? That would make it clear how the lookup is actually done. While I agree that making the docs unnecessarily pedantic is probably a bad thing, I am going to guess that I am not the only person that looks to them for technical accuracy. Regards, -Joe On Thu, Jul 27, 2017 at 4:04 PM, R. David Murray wrote: > > R. David Murray added the comment: > > I agree with Raymond. I'm not sure that adding roughly is going to > decrease the possibility of confusion, but I won't object to it. > > In a way, it's too bad we didn't make the attribute lookup machinery look > up all dunder methods on the class, so that a.__index__ would call the > class method. I think backward compatibility prevented that. > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue31042> > ___ > -- ___ Python tracker <http://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
New submission from Joseph Fox-Rabinovitz: The docs for [`operator.index`][1] and `operator.__index__` state that > Return *a* converted to an integer. Equivalent to `a.__index__()`. The first sentence is correct, but the second is not. First of all, we have the data model [docs][2]: > For custom classes, implicit invocations of special methods are only > guaranteed to work correctly if defined on an object’s type, not in the > object’s instance dictionary. Secondly, we can make a simple counter-example in code: ``` import operator class A: def __index__(self): return 0 a = A() a.__index__ = (lambda self: 1).__get__(a, type(a)) operator.index(a) ``` The result is of course zero and not one. I believe that the docs should read something more like one of the following to avoid being misleading: > Return *a* converted to an integer, if it is already an integral type. > Return *a* converted to an integer. Equivalent to `type(a).__index__(a)`. Or a combination of both: > Return *a* converted to an integer, if it is already an integral type. > Equivalent to `type(a).__index__(a)`. [1]: https://docs.python.org/3/library/operator.html#operator.index [2]: https://docs.python.org/3/reference/datamodel.html#special-method-lookup -- assignee: docs@python components: Documentation messages: 299195 nosy: docs@python, madphysicist priority: normal severity: normal status: open title: Inconsistency in documentation of operator.index type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
Changes by Joseph Fox-Rabinovitz : -- type: behavior -> ___ Python tracker <http://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
