[Python-Dev] [OT] stats on type-inferencing atomic types in local variables in the stdlib

[Brett C.]

Armin Rigo wrote:
> Hello Brett,
> 
> On Thu, Sep 30, 2004 at 01:02:34PM -0700, Brett C. wrote:
> 
>> (101, ('BINARY_MULTIPLY', (8, 4))),
>> (106, ('BINARY_SUBSCR', 128)),
>> (118, ('GET_ITER', 128)),
>> (124, ('BINARY_MODULO', None)),
>> (195, ('meth_join', 4)),
>> (204, ('BINARY_ADD', (8, 8))),
>> (331, ('BINARY_ADD', (4, 4))),
>> (513, ('BINARY_LSHIFT', (8, 8))),
>> (840, ('meth_append', 128)),
>> (1270, ('PRINT_ITEM', 4)),
>> (1916, ('BINARY_MODULO', 4)),
>> (12302, ('STORE_SUBSCR', 64))]
> 
> 
> I was surprized at first to see so few operations involving integers.  There
> isn't even LOAD_SUBSCR for a list and an integer, though I believe it to be a
> very common operation.

It's picked up and listed above; 106 times.  I already type check that lists 
are being indexed by integer or an object so I didn't bother to keep separate 
stats for those two cases.

>  It makes me guess that your type-inferencer does not
> recognize 'i' to be an integer in constructions like
> 
>   for i in range(...)
> 
> ?

Right, I don't infer those situations.

>  If so, it might be worth considering that some built-ins (most likely
> range(), len(), enumerate()) should be treated specially.  Remember there was
> also discussion in this list at some point about the compiler producing
> opcodes like BUILTIN_LEN.  This means that it might be acceptable to break the
> precise semantics (which involve looking up the name 'len' or 'range' in the
> globals first) and just special-case these common built-ins.
> 

Not going to break semantics for my thesis (the whole was not to), but this is 
all going to be mentioned in the Future Work section on what can be done to 
improve the situation for type inferencing.  It would definitely help if 
built-ins were known at compile-time, but since I have limited time I had to 
limit myself to what could be done without adding features to the compiler 
beyond just type inferencing.

-Brett