On Wed, Aug 11, 2010 at 8:43 AM, Lisandro Dalcin <[email protected]> wrote: > On 11 August 2010 09:32, Stefan Behnel <[email protected]> wrote: >> Hi, >> >> Hudson reports two test failures since the patch for #561 was pushed: >> >> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py31-c/269/testReport/ >> > > Well, I wrote that test, and I would be in favor of changing the test, > unless there is an obvious fix in order to support such code (after > all it is valid Python, right?) ... Anyway, special methods are, well, > special :-) and I'm not sure it is worth to should support things like > "__int__ = something" in a cdef class
I'll write a patch that fixes these problems. For T287, should I fix the doctest or the #561 patch? Before #561, if a cdef class defined __long__ and not __int__, then they would get both __int__ and __long__ methods available from Python (where the __int__ wrapper was generated by Python and the __long__ wrapper was generated by Cython). After #561, this is still true for Python 2 (except that the __long__ wrapper is generated by Python), but for Python 3 only an __int__ method is available from Python. In favor of the current post-561 behavior: who cares if there's a __long__ method under Python 3 (that's not backed by a type slot)? It's very unlikely that anybody would try to call it anyway, since most values won't have __long__ methods. (Also, reverting this part of the patch goes back to the bad performance case on __long__ -- probably not too important, but I thought I'd mention it.) In favor of reverting: The user wrote a __long__ method; they should get a __long__ method. Opinions? Carl _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
