Building CPython

[BartC]

On 15/05/2015 09:59, Marko Rauhamaa wrote:

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

What /is/ a method lookup? Is it when you have this:

  A.B()

and need to find whether the expression A (or its class or type) has a 
name B associated with it? (And it then needs to check whether B is 
something that can be called.)

If so, does that have to be done using Python's Dict mechanism? (Ie. 
searching for a key 'B' by name and seeing if the object associated with 
it is a method. That does not sound efficient.)

(And I guess Python's classes come into play so if B is not part of A's 
class then it might be part of some base-class. I can see that it can 
get complicated, but I don't use OO so can't speculate further.)

(In the language whose implementation I'm comparing with CPython's, it 
doesn't have classes. A.B() can still appear, but .B will need to be an 
attribute that the (bytecode) compiler already knows from a prior 
definition (usually, some struct or record if A is an expression).

If there is only one .B it knows, then a simple check that A is the 
correct type is all that is needed. Otherwise a runtime search through 
all .Bs (and a compact table will have been set up for this) is needed 
to find the .B that matches A's type. But this is all still pretty quick.

In this context, A.B will need to be some function pointer, and A.B() 
will call it.)

-- 
Bartc