When reviewing the fix for issue1172711 it was discovered that the 'array' module allows for '__int__' conversions:

>>> import array, struct
>>> a = array.array('L', [1,2,3])
>>> class T(object):
...     def __init__(self, value):
...         self.value = value
...     def __int__(self):
...          return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, 9)
>>> a
array('L', [9, 2, 3])
>>> a[0] = T(100)
>>> a
array('L', [100, 2, 3])

As discussed in issue1172711, this behavior may not be desirable.  We should look at deprecating '__int__' and adding '__index__' as was done for the struct module in issue1530559.

I just discovered that struct packs pointers from objects with an
__index__() method. Is that intentional?

>>> import struct
>>> class IDX(object):
...     def __init__(self, value):
...         self.value = value
...     def __index__(self):
...          return self.value
... 
>>> struct.pack('P', IDX(9))
b'\t\x00\x00\x00\x00\x00\x00\x00'
>>>

Yes, that's intentional.  When use of __int__ was deprecated, a bug report popped up from someone who wanted to be able to have their own objects treated as integers for the purposes of struct.pack.  (I don't recall which issue;  Meador, do you remember?)  So we added use of __index__ at that point.

I think __index__ is the right interface for something to expose if it wants to be usable as an integer, and this usage is consistent with the original __index__ PEP.

Mark Dickinson <report@bugs.python.org> wrote:
> Yes, that's intentional.  When use of __int__ was deprecated, a bug
> report popped up from someone who wanted to be able to have their own
> objects treated as integers for the purposes of struct.pack. 
> (I don't recall which issue;  Meador, do you remember?)
>  So we added use of __index__ at that point.

Yes, I think that's #1530559, and the bug report was about PyCUDA. I can
see why 'bBhHiIlLqQ' allow __index__(), since they previously allowed
__int__().

I specifically meant the 'P' format. As far as I can see, PyLong_AsVoidPtr()
never allowed __int__(), but now index objects can be packed as pointers.
It isn't a big deal, I just have to know for features/pep-3118.

To illustrate, this is python2.5.0; INT is an object with an __int__() method:

'\x07\x00\x00\x00\x00\x00\x00\x00'
>>> struct.pack('P', INT(7))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/stefan/hg/r25/Lib/struct.py", line 63, in pack
    return o.pack(*args)
struct.error: cannot convert argument to long
>>>

> I specifically meant the 'P' format. As far as I can see, PyLong_AsVoidPtr()
> never allowed __int__(), but now index objects can be packed as pointers.
> It isn't a big deal, I just have to know for features/pep-3118.
>
> To illustrate, this is python2.5.0; INT is an object with an __int__() method:
>
> '\x07\x00\x00\x00\x00\x00\x00\x00'
>>>> struct.pack('P', INT(7))
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "/home/stefan/hg/r25/Lib/struct.py", line 63, in pack
>    return o.pack(*args)
> struct.error: cannot convert argument to long

Huh, that's interesting.  It doesn't allow 'unsigned long' packs either (2.6.7):

Python 2.6.7+ (unknown, Sep 16 2011, 09:53:25)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> class IDX(object):
...     def __init__(self, value):
...         self.value = value
...     def __int__(self):
...          return self.value
...
>>> for code in ['l', 'L', 'P']:
...    try:
...       struct.pack(code, IDX(9))
...    except Exception as e:
...       print "pack('%s'): %s" % (code, e)
...
'\t\x00\x00\x00'
pack('L'): unsupported operand type(s) for &: 'IDX' and 'long'
pack('P'): cannot convert argument to long

The behavior around '__int__' in previous versions seems somewhat accidental.

Meador Inge <report@bugs.python.org> wrote:
> The behavior around '__int__' in previous versions seems somewhat accidental.

I think struct followed the functions in longobject.c, which is not
really consistent with respect to duck typing. See also #12965 or
http://bugs.python.org/issue1172711#msg48086.

But I think that the decision to accept __index__() for both signed
and unsigned integer formats is good for consistency.

For 'P' I'm not sure, but course it might be used in the wild by now.

See more general issue36048.