> I agree that consistent behaviour is good, but I don't see the point > of the "proof=True" option: Catching an error is not more difficult > than putting an extra argument "proof=False".
I am not sure about this. In the current implementation, none of the intermediate methods (e.g. for quotient rings, there's "is_field" calling "is_maximal", but in principal many more methods might be involved!) catch any errors. I don't think that it is the right approach for the user methods to catch any errors in this case. If there was only one type of error that could occur, I would share your opinion, but in that case propagating the error would be essentially the same as returning "None" as you suggest. In particular with the typical use case in mind, I think the user should be presented with a method to suit this, without throwing any errors. > What do you think about returning "None" if the answer can't be > determined? > > Namely, the typical use case in existing programs should be > if R.is_field(): > run some special algorithm > else: > do the generic blurp I think I'd prefer the other suggestion, namely leaving the default behaviour of methods like "is_field" as it is at the moment (thereby not breaking any other code!) and introducing an optional argument to specifically suit the typical use case. Sebastian --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
