> Mark, just to clarify a bit, the behavior is already there in the array module

Okay, understood.  But the new 'long long' support provided by this patch still allows for __int__-based duck typing, right?

>>> array('Q', [1, 2, Decimal(3.2)])
array('Q', [1, 2, 3])

That's the new duck typing I meant.  I see this acceptance of things with an __int__ method as a mistake, and my gut reaction earlier was that it seems wrong to propagate that mistake into the new long long functionality, even though it's already present in other places in the array module.

On second thoughts though, it would be a peculiar inconsistency to be able to pass Decimal objects to array('L', ...) but not to array('Q', ...).  So probably better to accept this behaviour for now, and open another issue for the __int__ / __index__ discussion, as you suggest.

BTW, the patch and tests look good to me, and all tests pass here (OS X !0.6, 64-bit) (Well, not quite true, but I fail to see how these changes could be responsible for the test_socket and test_packaging failures I'm seeing :-).  I get compile-time warnings from the 'int' declarations that should be 'Py_ssize_t', but I understand that's taken care of already...