Lisandro Dalcin wrote: > On Fri, Apr 17, 2009 at 1:52 PM, Stefan Behnel wrote: >> I don't see a major use case either, but calling nb_int when we convert to >> a C-int or a smaller type might still make sense in Py2. > > Well, my implementation first check if nb_long exists, if not, it > checks nb_int. So all this work just fine in Py2.
What I meant was: if we convert to a type that fits into a C int, we should prefer nb_int over nb_long, not the other way round. >> Note that Py2 allows __int__() to return a PyLong if the value doesn't fit >> into a PyInt, while __long__() must return a PyLong: > > Then I would vote for getting rid of "nb_long" at all, and always fill > "nb_int" with these rule: > > 1) if "__int__()" is implemented, always use it and ignore > "__long__()" if present, then fill the "nb_int" slot in Py2/Py3, and > set "nb_long"/"nb_reserved" to NULL. > > 2) if only "__long__()" is implemented, then fill the "nb_int" slot in > Py2/Py3, and set "nb_long"/"nb_reserved" to NULL. I think you say this because it follows the Py3 rules. I'm fine with that, but I do think that we should use both methods in Py2 if defined. So 1) should only apply to Py3. Given that there is no obvious use case for __long__, I also think that defining it should emit a deprecation warning in general, not only in case 2) Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
