Building CPython

[Marko Rauhamaa]

Gregory Ewing <greg.ewing at canterbury.ac.nz>:

> BartC wrote:
>> It appears to be those "<=" and "+" operations in the code above
>> where much of the time is spent. When I trace out the execution paths
>> a bit more, I'll have a better picture of how many lines of C code
>> are involved in each iteration.
>
> The path from decoding a bytecode to the C code that implements it can
> be rather convoluted, but there are reasons for each of the
> complications -- mainly to do with supporting the ability to override
> operators with C and/or Python code.
>
> If you removed those abilities, the implemention would be simpler, and
> possibly faster. But then the language wouldn't be Python any more.

I agree that Python's raison-d'être is its dynamism and expressive
power. It definitely shouldn't be sacrificed for performance.

However, in some respects, Python might be going overboard with its
dynamism; are all those dunder methods really needed? Must "false" be
defined so broadly? Must a method lookup necessarily involve object
creation?


Marko