> well, deprecating ".T", etc, just because it breaks an emacs mode, looks like > a huge overkill, especially from the vim camp :-\)
Ah, you misunderstand me. I'm not arguing against the sugar due to the Emacs mode - I'm arguing against the sugar because it's Bad For Consistency. > Besides, ".T" is bog-standard all over the numerical world. Removing nice > syntactic sugar should not be done so easily. >From that point of view, I would agree that there should be a *method* "Matrix.T()". Leaving out the parentheses by making T a property is a micro-optimisation which is bad for consistency reasons. The fact that Matrix.I throws an exception in the general case is even worse. There was a discussion on sage-devel a while back involving properties, and multiple people posited that it was sick to make a property that often throws exceptions... > I don't quite understand the problem however. Are you saying that emacs mode > triggers an attempt to actually compute ".T", etc, when you do > tab completion? The Emacs mode was simply how I stumbled across the issue, because it -- incidentally -- *does* currently break tab-completion. Exactly why this happens is not clear to me, but apparently pressing m.<tab> in ipython-mode will call all properties on m; if one of those throw an exception, the method poll is cancelled and the lisp code determines that m has no methods at all. m.I throws an exception if m is singular. This is clearly a problem with ipython-mode! But as I said: I'm not against the properties on Matrix due to that Emacs mode but because it's inconsistent, and hence confusing, syntactic sugar. 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.
