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