This is the issue, which is also the issue with the __richcmp__ (you'll need to remove that and __cmp__ to get __hash__ to work).
http://webmaster.iu.edu/tool_guide_info/python/api/type-structs.html This field is inherited by subtypes together with tp_richcompare and tp_hash: a subtypes inherits all three of tp_compare, tp_richcompare, and tp_hash when the subtype's tp_compare, tp_richcompare, and tp_hash are all NULL. - Robert On Nov 13, 2007, at 12:32 AM, Joel B. Mohler wrote: > > Hi, I think this question is almost certainly for Robert Bradshaw, > but I'd be > happy to get an answer anywhere! :) > > I'm rewriting some of the polynomial __hash__ functions to respect > the == > operator with (some of) the inclusions amongst polynomial rings and > mpolynomial rings. To this end, I want to implement __hash__ in the > class "Polynomial" (polynomial_element.pyx) and "MPolynomial" > (multi_polynomial.pyx) and have the rest of the polynomials inherit > this > implementation. However, I'm getting an error message "unhashable > type" on > some of the derived classes. It seems like a build error, but I've > touched > all the *.pyx files in the sage/rings/*/* directories and rebuilt > and the > error persists. > > Strangely (very strangely, indeed, to me), some of the subclasses > cooperate > just fine, but some of them do not: The following give the error > message > unhashable type when I call hash(x) where x is of the type listed: > MPolynomial_libsingular > Polynomial_generic_dense > But, the following types work perfectly fine: > MPolynomial_polydict > Polynomial_integer_dense_ntl > Note that 'Polynomial_integer_dense_ntl' is cython so a totally > cython-ed > inheritance works at least one place. > > Questions: Should inheriting __hash__ implementations in a cython > class work? > Would C++/C differences matter (there's a smattering of both in these > classes)? A patch against 2.8.12 is at > http://kiwistrawberry.us/research/hash-patch-2_8_12.patch > if you want to see actual code. > > As for the implementation, I'll note that one of my concerns is > that I was > going to have to write really nasty low level code to make this > fast, but it > turns out that my implementation is already faster than the current > 2.8.12 > and the code is quite decent (i.e. more pythonic than c-like). > Actual speed > comparisons vary greatly amongst classes, but it's clear that > there's more > optimizations to do around the corners in the poly classes (in > particular > some of the __getitem__ implementations are pretty slow). > > -- > Joel > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
