Dear Burcin, On 20 Mrz., 15:37, Burcin Erocal ... > I don't think comparing the methods implemented by two different > classes will be a good basis for testing an API specification > (assuming one day we write one). More specialized classes implement > some functions, which the generic ones don't. It will be a rare > occasion to see this command return True. > > sage: len(compare_methods(foo, bar)) == 0
Sure. But at least it helps to simplify the hand work in detecting what should be unified (if one sees that foo has the method lm() and bar has the method lead_monom(), for example). Burcin, I understand your first mail in that way: One should provide a table of methods with a specified purpose, and any class of `polynomials` must provide them. Of course, special classes may provide further methods, but the items on the list are common to all of them. This would make duck typing easier. E.g., polynomials should be addable, multiplyable, have a parent, have a base_ring (so far, we have an algebra element), be callable, have methods lm, lc, lt (or lead_monom, lead_coef, lead? This is something to be agreed on), etc pp... I think it is not my call to provide such list. But next week I can go through the list of methods of multi- and univariate polynomials, open a ticket for their unification, and perhaps start a poll on sage-devel concerning the suggested method names. Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
