Coerce that can pay attention to type of operation

Martin von Loewis loewis at informatik.hu-berlin.de
Tue Oct 3 17:17:55 CEST 2000


jepler.lnk at lnk.ispi.net (jepler epler) writes:

> 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.

Indeed, it is.

> 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?(*)

If the coerce that is being called is a instance method or function
object, then yes, it would be possible to know in advance. If it is
builtin, then there would be currently no way.

For P3K, it would be certainly acceptable to change the signature of
__coerce__ - even if that would mean to break code. Likewise, perhaps
P3K would provide a mechanism to analyse the signature of builtin
methods in advance (of course, builtin methods often process *args
**kw, so that would not say anything).

> 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).

All semantical issues aside, I don't like the name __coerce3__; these
magical names should not have numbers in them.

[floats, rationals, and reals]
> Hum, yes, if I wrote differently above, it was wrong.

No, you did not say anything about about adding floats and reals.

Regards,
Martin



More information about the Python-list mailing list