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