> > > If one looks at the documentation because an exception is raised then > there is no problem. The problem occurs when the user expects > something and Sage does something else, without any error/exception. > > THIS is what costs time. The special notation for the cycle > permutation, this hellish -1/+1 difference between p[] and p(). It > takes forever to find this out. >
When Sage does something different than what I expect, I look at the doc instead of wondering why it's different and being angry about it. Also again, different operations for p[] and p(). How long do you spend on figuring out why 2 + 2 != 2 / 2 because you were confused the operators look similar (well, when writing the division operator)? >From this discussion you see that people got in trouble because of > that, and changing the doc will make no difference. You don't read the > doc of every single function you use. You read the doc when you look > for a feature, a new flag or something. Or when you can't guess the > behaviour. You don't read the doc of "is_prime" when you want to test > if an integer is prime. > > When you type Permutation((1,2,3)) you expect it to return the same as > Permutation([1,2,3]), and when you type p(1) you expect the same as > p[1]. Documenting a bug does not fix it. > > It's not a bug because it's not doing something wrong. It's just doing something different than you expect. Moreover I would not necessarily expect those two to behave in the same way because I'm giving different input; especially for p(1) and p[1]. Best, Travis -- 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.
