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

[Armin Rigo]

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 makes me guess that your type-inferencer does not
recognize 'i' to be an integer in constructions like

  for i in range(...)

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


Armin