const for bytecode optimization...

[Michael Hudson]

"Michal Wallace" <sabren at manifestation.com> writes:

> hey all,
> 
> you know... I was just thinking... someone posted about the const operator
> a day or two ago... and the response was generally that you don't need it
> because you can do THIS_KINDA_THING or even const.this ....
> 
> But there's another thing that const gets you... Java, for example, can use
> static final variables (constants) as a sort of bytecode optimizer, in place
> of c style #IFDEF 's
> 
> for example, say you had:
> 
> DEBUG = 0
> 
> # call various functions any one of which might change DEBUG
> 
> if DEBUG:
>     # nothing in here needs to be compiled into the .pyc
>     pass
> 
> from what I understand, the optimizing compiler doesn't do anything yet,
> maybe this could be a start..

The time machines strikes again (and again and again ...). The
variable you are looking for exists.

It is called __debug__:

[mwh21 at atrus mwh21]$ python -O
Python 1.5.2+ (#13, Jan 14 2000, 09:26:45)  [GCC 2.95.2 19991024 (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> def f():
...  if __debug__:
...   print 1
...  print 2
...
>>> f()
2
>>> import dis
>>> dis.dis(f)
          0 LOAD_CONST          1 (2)
          3 PRINT_ITEM
          4 PRINT_NEWLINE
          5 LOAD_CONST          0 (None)
          8 RETURN_VALUE
>>>

> of course, you could also just enforce the ALL_CAPS as being
> constant, and not allow them to be redefined, but this could break
> someone's code if they didn't follow that convention...

There's definitely mileage in making the compiler a little cleverer.

In the mean time, there are a few packages that will do post hoc
optimization; my bytecodehacks package is one, Skip Montanero has
another.

There's not *too* much mileage here without doing type
analysis/annotation of one sort or another, and that's a *hard*
problem (see December Types-SIG, for instance).

Cheers,
Michael