Home Original page

Coerce and multimethods (was Re: Inefficiency of __getattr__)

Huaiyu Zhu hzhu at users.sourceforge.net
Mon Oct 2 15:09:50 EDT 2000 
On Mon, 02 Oct 2000 17:52:18 GMT, Kragen Sitaker <kragen at dnaco.net> wrote:
>In article <slrn8tggpc.572.hzhu at localhost.localdomain>,
>Huaiyu Zhu <hzhu at users.sourceforge.net> wrote:
>>
>>coerce (x, y) 
>>      Return a tuple consisting of the two numeric arguments converted to a
>>      common type, using the same rules as used by arithmetic operations.
>>
>>Does this mean
>>
>>    a+b == apply(a.__class__.__add__, a.__coerce__(b))
>
>Yes, I think so, although I think it uses the __add__ from the first
>element of the tuple, not from a.

That would make it quite useless in my case. Yet the simple do-nothing
__coerce__ still consumes as much time as the actual computation, although
__getattr__ uses 6 times more.

>Keep in mind that automatic type coercions are really evil; they are
>partly justified for numeric types, but I'm reluctant to have them even
>there.  The problem is that their presence vastly increases the number
>of possible ways to misunderstand your program.

And they are quite unecessary.

Sometime ago there was a brief discussion of multimethods here.  The idea is
that a+b will be dependent on the classes/types of both a and b.  I did not
quite understand it at the time.  But now it looks to me like that
__coerce__ is simply an awkward way of doing it half-heartedly.

In another thread yesterday someone suggested a three way coerce, using the
operation as a third argument to fine tune the coersion.  That would still
leave out the info about the original operands, though.  A multimethod would
solve all these in a much cleaner way.

Short of that, maybe we should propose to use __coerce__ only for builin
(numeric) types and explicit coerce calls?  What are the most significant
applications that use coerce, anyway?  In any case, an explicit call like

def __add__(a, b):
  a, b = coerce(a, b)
  return a+b

would give back current behavior without exacting a heavy toll on everybody
else. 

>
>One of Python's biggest advantages over Perl is that it doesn't have
>automatic conversion between strings, lists, hashes, and references;
>between integer and floating-point; or between strings and numbers.
>Many, many times I've fed Perl a program that was utterly nonsensical
>(subtracting references from numbers, for example; a particularly
>egregious case, because if you coerce a reference first to a string,
>then to a number, you get 0, but if you coerce it straight to a number,
>you get a unique number, like Python's id()) and had it run and produce
>wrong results.
>
>Every time I've argued static versus dynamic typing with a
>static-typing fan, they've ended up concluding that what they really
>hate is not dynamic typing but silent coercions.

Right there.

-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net
More information about the Python-list mailing list