Raymond Hettinger wrote: > For the alpha, I've left all of the traps off except for > ConversionSyntax. I agree with Michael Chermside list of traps that should be on by default. As a potential user of Decimal, I'd much rather start off with training wheels *on*. I can always take them off myself later. Going back to Tim Peters' post from a few days ago, Tim Peters wrote: > Note that I've suggested that some trap-enable flags should be set > by default for Python: those for invalid operation, divide by 0, and > overflow. ... > That's one reason I want Python to enable the invalid-operation trap > by default. That choice isn't suitable for all apps all the time, > but I have no hesitation Pronouncing that it will be suitable for > most Python apps most of the time. Tim also wrote, "Errors should never pass silently, unless explicitly silenced." I put high value on Tim's opinions in matters mathematical, and so does Guido: he delegated to Tim on PEP 327. That brings up a point: although marked "Final" in CVS, I never saw an official "Accepted" pronouncement from Tim or Guido. So, just for the record, Tim, do you agree that PEP 327 should be marked Accepted & Final? Michael Chermside wrote: > Signal Should it raise by default? And why? > ------ ------------------------------------ > Clamped Yes - well, maybe. When could we ever generate this? > ConversionSyntax Yes - it prevents lots of possible user errors > DivisionByZero Yes - other numeric types raise for this in Python > DivisionImpossible Yes - I don't fully understand it but it seems bad > DivisionUndefined Yes - other numeric types raise for this in Python > Inexact No - this is perfectly normal > InsufficientStorage N/A - this doesn't exist in the Python implementation > InvalidContext Yes - I don't understand how this could happen, but > surely we should complain about it, right? > InvalidOperation Yes - Users want exceptions when doing invalid math > Overflow Yes - overflows lose data, so we should raise > Rounded No - this is perfectly normal > Subnormal No - this is perfectly normal (subnormal?) > Underflow No - since Inexact, Rounded, and Subnormal are all > unreported, this should be also! Tim, do you agree with this list? Any changes? I think the decision of which signals to trap (convert to Python raised exceptions) should be added to the PEP. (Hmmm. There seems to be a mismatch between the PEP and the implementation. The "signals" listed above are listed as "conditions" in the PEP, and according to the PEP, the "invalid-operation" signal covers several conditions: conversion syntax, division impossible & undefined, invalid context, and invalid operation. See <http://www.python.org/peps/pep-0327.html#exceptional-conditions>.) -- David Goodger <http://starship.python.net/~goodger> Python Enhancement Proposal (PEP) Editor <http://www.python.org/peps/>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4