On Fri, Apr 17, 2009 at 4:14 PM, Stefan Behnel <[email protected]> wrote: > > 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. >
Well, to do it the right way, nb_int it should take precedence if the type fits in a C int, or if it fits in a "signed long" but not "unsigned long". It seems that I was lazy, though I've actually tried to maintain the implementation of _Pyx_PyNumber_Int() simple and make it take a single argument (like the one in core CPython). I'll try to review my work and provide a patch, though I'm not sure if further work will pay that much... For core CPython types, the only case where all this can have some impact in for float -> int conversion. > >>> 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. > As I've started to work on a patch, let put it clear case by case... Python 2 ---------- a) if only __int__(), fill as "nb_int = __int__" and "nb_long = NULL" b) if only __long__(), fill as "nb_int = __long__" and "nb_long = NULL" c) if __int__() AND __long__(): fill as "nb_int = __int__" and "nb_long = __long__" Python 3 ---------- a) if only __int__(), fill as "nb_int = __int__" and "nb_reserved = NULL" b) if only __long__(), fill as "nb_int = __long__" and "nb_reserved = NULL" c) if __int__() AND __long__(): fill as "nb_int = __int__" and "nb_reserved = NULL" So only cases (c) makes a difference for Py2/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) > I'm fine with that, but I'll likely ask you to do the work :-) -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
