I think the inspect module could be useful in deployed production
code: if you have a function with side effects, such as:
def update_and_return(value):
# 1. store value in database
# 2. read another value from database
# 3. do some very heavy calculations based on the passed
# value and the one you just read in from the database
...
return calculated_result
Of course this is a trivial example (and you would simply split it
into two functions), though using inspect, it'd be possible to
determine if the return value is *ever* used. This includes being
assigned to a variable that's ever read (this check would be disabled
during interactive use), or if it's passed into another function, ala
"foo(update_and_return(5))", that ever uses that variable (with
special considerations for *args, **kwargs, and other constructs).
Such functionality would be nice to have functools as an optimized c-
routine, and could be used as such:
from functools import returning # this doesn't actually exist
def update_and_return(value):
# 1. store value in database
if not returning():
return
# 2. read another value from database
# 3. do some very heavy calculations based on the passed
# value and the one you just read in from the database
...
return calculated_result
The ast module is also worth looking into. I was trying to use it to
leverage python's already pseudo-code like qualities for user
customization in an grad-level CS theory class assignment by allowing
(the grader) to code a very abstract problem definition (without even
the optimizations you do subconsciously). The program would leverage
the interpreter to do the parsing, and then I would rearrange and
prune the parse tree in various ways, most commonly by inspecting the
code of boolean filter functions (which of the elements are worth
considering?) that took potentially millions of input elements and
returned a few dozen outputs, and creating generators that only
yielded those same few dozen elements without having to scan the input
sequence (based on rules governing the input elements, and assumptions
about the supplied filter functions).
Let's just say it turned out to be a lot faster than programs from
those students that were counting on C++ being fast enough for such
brute-force code -- pity that much of academia these days consists of
students that only know (or even know of) one programming language
(some of which believe that, like the "Windows and Mac" of the
computing world, there are only a handful of choices out there).
On Aug 26, 8:53 pm, GoldenTiger <goldenboy...@gmail.com> wrote:
> do you refer to module inspect? it's great for introspecting on live
> objects and their source code
>
> On 27 ago, 03:44, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > I discovered this:
>
> > def f(name):
> > import inspect
> > c_frame = inspect.getouterframes(inspect.currentframe(), 1)[1][0]
> > c_args, c_varargs, c_varkw, c_locals =
> > inspect.getargvalues(c_frame)
> > d = dict(c_locals)
> > return d[name]
>
> > def g():
> > a=5
> > print f('a')
>
> > g() # prints 5
>
>
