On Mar 11, 2009, at 9:38 AM, Bill Page wrote:
> > On Wed, Mar 11, 2009 at 12:15 PM, Georg S. Weber wrote: >> On 11 Mrz., 14:06, Bill Page wrote: >> >>> I think the new coercion model in Sage is much too aggressive - >>> especially as applied when coding. As Ralf said: perhaps it makes >>> sense for interactive use. Would it be possible to enable/disable >>> some >>> features dynamically? [...] > I am just talking about optionally disabling certain coercions in > designated segments of Python code, thus requiring/enabling the > programmer to be more explicit in certain cases and allowing the type > system to catch more potential errors. I am not a fan of lots of different modes that change actual behavior, it tends to make code a lot harder to follow. Widening the rift between interactive and library code is also a bad idea--the fact that they are so close now is certainly a large factor in the number of developers and rate of development. Currently there is a coercion_traceback mechanism to see what errors were caught--it would be easy to make a verbose flag where exceptions and/or tracebacks were printed rather than just cached. Also, as is the topic of the other thread, I plan on making the exceptions caught a lot tighter. >> From the point of view of code quality, the above story about >> infinite >> Weyl groups sounds to me that now, that code is better than before. >> I.e. it would work seamlessly whether the coercion model would be >> strict or not-so-strict as it is now. This clearly is a sign of >> greater >> robustness, and of the programmer having stated more precisely >> what the code really is supposed to do (and what not). Though we only got the tail end of this story, it didn't seem like coercion was required to run into this bug, it just happened to expose it. > The point is not that it is time-consuming per se, but rather that it > is error-prone, i.e. time spent debugging versus time spent coding. > How much of the work of ensuring "correctness" do you want the type > system to do versus how much testing will be required later? Short of suppressing errors (see above) are there any concrete examples where coercion sacrificed correctness or prolonged debugging time? - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send 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 -~----------~----~----~----~------~----~------~--~---
