+1 for Carl's proposal with the addition that it should mention the "unevaluated if" functionality if/when it becomes available in sage (heck, maybe it should just point to the relevant threads or trac tickets in the interim...)
On Apr 12, 7:33 pm, Carl Witty <[EMAIL PROTECTED]> wrote: > On Apr 12, 8:58 am, Jason Grout <[EMAIL PROTECTED]> wrote: > > > > > Carl Witty wrote: > > > On Apr 10, 1:41 am, Simon King <[EMAIL PROTECTED]> wrote: > > >> On Apr 10, 4:18 am, Carl Witty <[EMAIL PROTECTED]> wrote: > > > >>> I like the "raise an exception" behavior, because it would eliminate > > >>> questions asking why form1 and form2 below are different (from this > > >>> sage-support > > >>> threadhttp://groups.google.com/group/sage-support/browse_thread/thread/79d0...). > > >>> (I have seen this exact problem at least twice on sage-support.) What > > >>> do you think? > > >> I guess what i suggest wouldn't solve the plot-issue. However, i think > > >> if one doesn't know whether an inequality holds, or if the inequality > > >> simply makes no sense (such as in the case of an unordered field) then > > >> bool() should neither raise an exception nor return False but return > > >> None. I think it is much simpler to have > > The reason why I eventually decided that throwing an exception was > > unpythonic was that I could not find a single case of current python > > code which did that. Actually, the one reference I did find was a > > bugfix to a project (I think SQLAlchemy), in which they changed > > __nonzero__ to not raise an exception since it was inconsistent with > > other behavior. > > > That, and the fact that Python by default returns True for objects > > instead of raising exceptions, tells me that raising exceptions would > > also raise an exceptional number of eyebrows and probably voices too. > > I agree that raising an exception is somewhat unpythonic, but I don't > think that's an automatic veto on the idea. Sage does lots of > unpythonic stuff already, and I think we should at least consider > adding one more unpythonic behavior in this case. > > I still think that most of the times people write "if x > 0:", they > will be implicitly wanting an unevaluated, symbolic conditional that > we can't automatically provide; in these cases, I think raising an > exception is much better than silently giving a result quite different > than what's desired. > > For the few cases where people actually understand the issues (and the > issues are complicated, involving two very different kinds of > variables and two very different kinds of evaluation), and write "if x> 0:" > wanting the current behavior, an exception is slightly worse > > than the current behavior; but if the exception points at a simple > workaround (by having "Use the .known_true() method to evaluate > unknown conditions to False" as part of the exception text) then the > cost is very small. > > So according to this analysis, raising the exception is a large > benefit (doesn't silently give the wrong answer) for a larger number > of novice users, and a small cost for a smaller number of expert > users. If this is correct, then I think we should raise the > exception. > > Carl --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
