> Otherwise, maybe it can be fixed on the relabel function level (once > again, > > I don't know how it works). > > I don't see how. I tried many times, and each time I was sent back to > this design problem: the default value of the list of vertices is not > properly defined, and good a good reason (i.e. the question I asked). > > Perhaps a dumb question, because I am not surprised that totally rewriting is challenging...
Could you in the interim use internally (for your purposes now) a new is_isomorphic (or perhaps is_really_actually_equal) method as Volker suggests, that could be easily replaced by (or replace) == once that works correctly? Or would that run into the infinite loop problem you mention at the ticket (though it seems like that issue has since been resolved/hacked around). I apologize if you have already answered this, but I didn't see exactly this question answered - perhaps because you are right that it's not just isomorphism. I agree this is not optimal. But I also can see that probably it is just too much work for any one person to completely restructure this, nor can this kind of thing happening be easily resolved without imposing a far more stringent structure on Sage development itself, which is already at times quite onerous (yes, I know I am sometimes one of the ones imposing that!). Anyway, unless you are exposing the (wrong) behavior directly in what you are working on, maybe this is better than nothing happening, both for you and the originator(s) of FinitePosets. If this is not a useful suggestion, again my apologies :( - kcrisman -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
