Which happens first?

Carlos Alberto Reis Ribeiro cribeiro at mail.inet.com.br
Sun Apr 8 17:29:40 EDT 2001


At 00:52 08/04/01 -0400, Tim Peters wrote:
>Because it does no optimizations, there's no supporting machinery for *doing*
>optimizations either, so "the first one" it tries is going to be more of a
>pain than you imagine.  In particular, negative integer literals don't exist
>in Python's grammar (only non-negative integer literals exist), and Python
>compiles straight from parse tree to bytecode.  So even that trivial little
>optimization would require a (non-existent) peephole optimizer doing pattern
>matching on the parse tree or bytecode stream.

Just curious, but is it so hard to change the grammar to detect negative 
integer literals? I know it involves a little bit of look ahead work, but 
there are well known techniques to handle it. On the other hand, I can see 
that this is not a big issue the vast majority of time (it would save only 
a few bytes of bytecode, and almost nothing on time...)

> > 5) Other strange thing: at least in this example, the compiler did
> > not made any optimization on constant expressions.
>
>Right, and it never does.  This isn't C, and Python assignments aren't
>macros, so doing stuff like
>
>TOTAL_BYTES = BYTES_PER_SECTOR * SECTORS_PER_TRACK * NUM_TRACKS
>
>at module level is a one-time module import cost, no matter how often
>TOTAL_BYTES is dynamically referenced later.  But, yes, doing that inside a
>loop is a Possibly Poor Idea.

Ok. So let's change my conclusion as follows: 'Avoid any calculation on 
literals inside loops in Python, as the compiler will not optimize 
anything. Put explicitly out of the loop everything that you can. This kind 
of code is optimized in some other languages/compilers, such as C or 
Pascal, but not in Python."

As always, it's good to make this point; people come to Python from very 
different backgrouns, and, for some of us, this may be a problem. In my 
case, I tend to use lots of small Python scripts to parse log files, some 
of them in binary format. So I end up coding stuff like this sometimes, to 
quickly get some information from inside complex records or structures. 
There are also some alternatives, such as the struct and re modules, where 
the coding style does not suffer from this problem.

> >  >>> p = a[(3*4+2)-1]   # get the second byte of the third DWORD
>
>I'll take your word for it that you find that easy to understand <wink>.

Ok, it was not a good example. Using pseudo literals (as your TOTAL_BYTES 
example) it's a better technique, specially in Python, where everything is 
referenced as an object, even the literals.

> > 2) If your expression involves value of mixed types, check
> > *carefully* the sequence of the calculation.
>
>That's crucial advice in any language.

Another good point. Maybe it should go in a reference document somewhere 
the documentation. The most obvious things are the easiest to overlook.


Carlos Ribeiro






More information about the Python-list mailing list