On Sat, Apr 12, 2008 at 5: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.
>

I vote +1 to Carl's proposal.

William

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to