ctypes ArgumentError lists arguments from 1, not 0

[perey]

BPO	14999
Nosy	@birkenfeld

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-10-13.20:42:42.090>
created_at = <Date 2012-06-04.05:50:04.967>
labels = ['ctypes', 'type-bug']
title = 'ctypes ArgumentError lists arguments from 1, not 0'
updated_at = <Date 2013-10-13.20:42:42.088>
user = 'https://bugs.python.org/perey'

bugs.python.org fields:

activity = <Date 2013-10-13.20:42:42.088>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = <Date 2013-10-13.20:42:42.090>
closer = 'georg.brandl'
components = ['ctypes']
creation = <Date 2012-06-04.05:50:04.967>
creator = 'perey'
dependencies = []
files = []
hgrepos = []
issue_num = 14999
keywords = []
message_count = 2.0
messages = ['162251', '199797']
nosy_count = 2.0
nosy_names = ['georg.brandl', 'perey']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue14999'
versions = ['Python 3.2']

[perey]

The ctypes ArgumentError exception indicates the location of the problem by argument number. It counts arguments starting from 1, not 0 as is typical in Python.

Observed
--------

An example (anonymised) traceback:
    Traceback (most recent call last):
        ...
        foreign_function(a, b, c, d)
    ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type

The error here was with the argument "b".

Expected
--------
Standard, zero-indexed Python counting would suggest that argument 2 should mean "c", and "b" would be argument 1.

Rationale
---------
This may be as intended, but for me it violates the principle of least surprise.

I *think* this is the vicinity of the bug:
http://hg.python.org/cpython/file/696d3631a4a1/Modules/_ctypes/callproc.c#l1103

_ctypes_extend_error(PyExc_ArgError, "argument %d: ", i+1);

If I'm right and the "i+1" (here and/or in subsequent lines) is the cause, that definitely makes it look intentional.

[birkenfeld]

IMO we always use 1-based numbering when counting things.

Try e.g.

>>> format('a', None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format expects arg 2 to be string or unicode, not NoneType