On Thu, Jul 15, 2010 at 6:36 PM, Fernando Perez <[email protected]> wrote: > On Thu, Jul 15, 2010 at 5:07 PM, Robert Bradshaw > <[email protected]> wrote: >> >> I think the trickier part is getting it from am interactive prompt, >> though IPython has done most of the hard work in this direction. >> > > Ugly but functional: > > http://github.com/ipython/ipython/blob/0.10.1/IPython/kernel/contexts.py#L110 > > So yes, obviously just like the sage notebook, since we have the > user's input we can get the source for interactively defined > functions. This is something you normally can't access because python > itself does not store that info. A while ago that was proposed, as a > __source__ attribute, but it was ultimately rejected: > > http://www.gossamer-threads.com/lists/python/dev/367506?do=post_view_threaded > > Which means for functions defined in files, these tricks are *very* > brittle. Given a function's code object, there are many ways in which > one can fail to get back its source: the __file__ attribute may be > mis-set (I've seen it from compilations in chroot environments, where > the path to the pyc is bogus), the import may come from a zip archive > without sources, etc. > > In a sense, sage/ipython are more robust here than python itself, > because they have full knowledge of the user's input history and can > access the source of all functions directly. But the analysis can get > tricky to get right for things that have been otherwise decorated, > dynamically generated, callable objects, etc. > > In summary, this can be made to work, but it will carry some restrictions.
Of course, as a fallback, we could try throwing some decompiler at the code object :). _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
