[Python-ideas] And now for something completely different
Terry Reedy
tjreedy at udel.edu
Sat Sep 20 18:46:06 CEST 2008
Cliff Wells wrote:
> You should be able to tell at compile-time which functions are affected
> (assuming we used a signature indicator. If a function has *any*
> deferred arguments, it is a special type
> <function-with-deferred-arguments> rather than plain <function>.
Compiling the function is no problem. Compiling and running the
function call is. The class of the object resulting from evaluating an
expression is generally not known until runtime. For callable
expressions, the only constant expression is a lambda expression.
>> And there will still be some runtime overhead in selecting
>> between the two cases.
>
> It depends on how selection is done already (say for functions vs
> methods).
Python has several callable classes. 'Function' and 'method' (3.0 name)
are just two of them. When the compiler sees 'e1(e2)', it assume that
the programmer intends e1 to evaluate to a callable and e2 to an
argument thereof. So it compiles code to evaluate e1, evaluate e2, and
then call e1 with arg e2.
The 'selection', such as it is, takes place in the evaluation of the
callable expression, by virtue of the class of the resulting object.
But the interpreter pays no attention to that, but simply tries to call
the presumed callable with the evaluated argument expression by looking
for the callable's __call__ method. Which is to say, there is no
selection as you seem to mean the term.
It is a simple and elegant design, but without major change, not very
amenable to your desire for runtime selection of arg processing and
passing method.
> If it's implemented via a type-selected vector then having> a
> separate type <function-with-deferred-arguments> then the overhead would
> be nil. If it requires explicit testing, then there would be at least a
> small overhead.
There is neither a vector nor explicit testing. The 'callable' is
called, and if it is not callable, the interpreter reports back
TypeError: 'whatever' object is not callable
Terry Jan Reedy
More information about the Python-ideas
mailing list