Coerce that can pay attention to type of operation
jepler epler
jepler.lnk at lnk.ispi.net
Sun Oct 1 20:21:03 EDT 2000
On 01 Oct 2000 22:08:50 +0200, Martin von Loewis
<loewis at informatik.hu-berlin.de> wrote:
>Nevertheless, please write a PEP (http://python.sourceforge.net/peps)
>on this subject, or have a look at PEP 208 :-). Something should be
>done, probably, but it will need a lot of planning.
Hum, is that PEP still blank? It was the last time I got a cvs update
of the sourceforge tree.
One begins to see that there may have been a problem that C++ was trying
to solve, given static typing and function overloading...
I see your point that another method lookup for each operation would
become unnaturally high in cost. If only we could determine at runtime,
and cheaply, that __coerce__ could take 3 arguments, this price would be
eliminated. Is this actually possible?(*)
I would propose that coerce(a,b) would call a.__coerce3__(b, None)
and that coerce(a,b,t) would also be accepted, calling a.__coerce3__(b, t).
One wart on this is that while $a*b$ can smartly call first
a.__coerce3__(b, "__mult__") and then b.__coerce3__(a, "__rmult__"), I don't
see how this could be done in the case of a 3-argument coerce().
>(*) I know that technically, rational numbers are a superset of
>floating point numbers (which are rationals with some base two
>denominator). I understand you don't want to treat them that way,
>though.
Hum, yes, if I wrote differently above, it was wrong. People
use floats as though they can store such quantites as sqrt(2.0),
but they shouldn't use Rational() that way. Thus, as you suggest,
adding a float and a rational should give float, just as in general
adding a real and a rational gives a real.
Anyhow, thanks for the food for thought.
Jeff
(*) I have also often wished that __str__ could take the width specifiers
given in the formatting operator, so that "%5.3s"%a would call a.__str__(5,3)
if a.__str__ is able to take arguments. Thus, objects would have the
opportunity to smartly format themselves in the available space.
More information about the Python-list
mailing list