Michael Orlitzky writes: > I have a matrix m... how come, > > * m.rank gives me bullshit > * m.rank() works > * m.T() crashes > * m.T works?
This is in my mind the most compelling reason to phase out properties in Sage. I think Erik makes many good points, but ultimately I think consistency is more important. The problems with ? and tab-completion seem manageable, so I leave that aside. In many ways, programming math is a software designers worst nightmare, where designing the good API that is logical and works in all cases quickly becomes daunting. Michael's example above is nice: the rank of a matrix is an invariant, so it should just be a read-only property, just like all the my-first-@property-tutorials tells us, right? But by that logic, tons and tons of zero-argument methods should be read-only properties in Sage. And if someone later on implements a clever algorithm2 for computing the rank of certain types of matrices, and would like to toggle that by an optional argument, @property is suddenly a problem. And so where would you draw the line? Properties are preciously little used in Sage. And I see no clear way of using them in a consistent manner, in the type of objects that is Sage. So I feel the rule of consistency tells us we should therefore not use properties at all (perhaps except for the types of exceptions discussed by Nicolas Thiery and Simon King). Best, Johan -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
