Expansion of the __debug__ and pass concepts

[Alex Martelli]

<c_ullman at yahoo.com> wrote in message news:8tn72t$8s6$1 at nnrp1.deja.com...
    [snip]
> I think there a couple of ways we could add this functionality
> in a generic way to python.
>
> 1) Create an IFDEF like, preprocessor system for python.

This one is really easy: you can define your own __import__
to do whatever preprocessing you like on Python sources
as they get imported (the library reference manual says of
__import__ that "It mainly exists so that you can replace it
with another function that has a compatible interface" to
change import semantics; library module imp offers a few
facilities that make such replacement really easy).

If you need the preprocessing to take place also on the
'top-level' .py file, the one directly submitted to the
python executable, then you do need to do a little C
level work (your own preprocessing-python executable),
but not that much, all in all.

I'm not sure that proposing "standardization" on a specific
preprocessor right now is appropriate.  Some will want
very minimal and fast text-level preprocessing, similar to
what the C preprocessor offers; others would prefer
richer functionality, say a la m4; others yet would vastly
prefer a _hygienic_ macro system a la Scheme/Dylan/
OCaml.  If you develop, document, and publish such a
preprocessor, you may get enough of a following to make
a PEP to incorporate it in standard Python worthwhile...


> 2) Improve the byte-code optimizer so if I did this:
>
> if __debug__:
>     def DBG(*args):
>        pass
>
> The optimizer would figure out that DBG never did anything and
> optimize it away.

Guido's time-machine may have the jump on you in this case.

This is exactly how __debug__ and -O cooperate: with
the -O, whatever is under an 'if __debug__' *does*,
already, get entirely removed (as do assert statements).

But having removed the definition of DBG means it
will be an error to try to _use_ DBG, then... not very
useful (and isn't the 'if __debug__' test the wrong
way 'round here? or maybe I don't understand what
exactly you mean...?)

> 3) Expand the concept of pass so that it will now take arguments.
> For example, all the following would now be legal python:
> pass
> pass(5)
> pass(5, x=6)
> etc...
>
> Then we could do this in python
> if __debug__:
>     DBG = pass

Again, do you mean 'if not __debug__:"...?

However, I doubt you do want that.  Python is NOT based on
normal-order, aka lazy, evaluation: all expressions are fully
evaluated (and the results bound to the corresponding
arguments) before the call happens.  So, if the call itself
is a no-op, you're still not going to save much if any of
the argument-expressions is costly to evaluate.  And
you'd also still be paying the runtime cost of looking up
the DBG identifier, which I think is comparable to the
cost of an empty call and return pair.

A combination of 1 and 2, i.e. taking advantage of the
existing optimization for 'if __debug__' (perhaps via a
very fast special-purpose preprocessing path) appears
much more suited to covering your needs, than having
the somewhat ad-hoc-appearing novelty of "pass with
optional arguments".


Alex