Mark Dickinson <dicki...@gmail.com> added the comment:
> 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...
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1172711>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
