On 2/9/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > > > Guido seemed accepting to this idea about 9 months ago when I spoke to > > him. I finally got around to writing up the PEP. I'd really like to > > get this into Python 2.5 if possible. > > -1 > > I've detailed my reasons here: > http://mail.python.org/pipermail/python-dev/2006-January/059851.html
I don't actually see anything relevant to this discussion in that post. > In short, there are purely math usages that want to convert to int > while raising exceptions from inexact results. The name __index__ > seems inappropriate for this, and I feel it would be cleaner to fix > float.__int__ to raise exceptions from inexact results (after a > suitable warning period and with a trunc() function added to math.) Maybe cleaner, but a thousand time harder given the status quo. Travis has a need for this *today* and __index__ can be added without any incompatibilities. I'm not even sure that it's worth changing __int__ for Python 3.0. Even if float.__int__ raised an exception if the float isn't exactly an integer, I still think it's wrong to use it here. Suppose I naively write some floating point code that usually (or with sufficiently lucky inputs) produces exact results, but which can produce inaccurate (or at least approximate) results in general. If I use such a result as an index, your proposal would allow that -- but the program would suddenly crash with an ImpreciseConversionError exception if the inputs produced an approximated result. I'd rather be made aware of this problem on the first run. Then I can decide whether to use int() or int(round()) or whatever other appropriate conversion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
