Comment #15 on issue 2305 by [email protected]: Integer.isqrt and similar shouldn't be a method
http://code.google.com/p/sympy/issues/detail?id=2305
I'm not sure why they shouldn't be methods (at least there was no explanation in this issue why -> "That's better, but I still think it should be a function, not a method." isn't very helpful here (this is a recurring pattern)).
First of all, methods like gcd() are defined not only for Integers but for numbers in general, so people that like OOP should be happy with this approach. Secondly, if we put factor() as a method (and many other), so why not gcd() and others? gcd() (function) can already handle gcd(2, 4) (etc.) case, but it does this by falling back to gcd() method of appropriate types. Lastly (at least for now): is (for example) factorint() better than Integer.factor() or Integer.ifactor()? (there is an obvious disadvantage of the former because one needs to import this function, but on the other hand you can do factorint(int) without conversion to SymPy's integer (although if we will ever use gmpy outside polys, then the conversion will happen anyway).
-- You received this message because you are subscribed to the Google Groups "sympy-issues" group. 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/sympy-issues?hl=en.
