Expansion of the __debug__ and pass concepts
Alex Martelli
aleaxit at yahoo.com
Wed Nov 1 12:55:45 EST 2000
<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
More information about the Python-list
mailing list