On Sun, May 27, 2012 at 2:27 PM, Makoto Kuwata <[email protected]> wrote:
> Hi Maciej, > > On Sun, May 27, 2012 at 7:45 PM, Maciej Fijalkowski <[email protected]> > wrote: > > Hi Makoto. > > > > sys._getframe(1).f_locals will stay slow. The reason for this is that you > > have to create all the locals and put them in a dictionary (they normally > > don't even exist on the heap). Because of that we decided the JIT should > > simply bail out and give up trying to optimize this particular code. > > I agree to PyPy team's decision. > Some points may be slower on PyPy, but almost of all is much faster > than CPython. > > > > Note > > that as documented on the python website, this functionality is mostly > for > > implementing debuggers and such (where speed does not matter), do you > > *really* need your callers locals? > > Yes. I need to access to caller's local variables in my product (= > Tenjin template engine) > and sys._getframe() is reasonable solution for it (at least in CPython). > > > > Sounds like a very deep magic to me, I > > can point you to this presentation [1] as to why it might be a bad idea. > > > > [1].. http://www.youtube.com/watch?v=8e0l_Dt28MQ > > I know that sys._getframe() is kind of black magic, but I must use it > because it is only the way to access to caller's local variables. > > My goal is to access to caller's local variables, and sys._getframe() is > just a way to reach to goal. > My point is mostly that style-wise the design decision that led you to "I need to inspect the callers variables" was probably not a very good one. It's very tempting to use black magic, because writing explicit passing of arguments is too verbose, but remember that explicit is always better than implicit. I won't try to convince you any more - it's more about style than about what can or cannot be made fast on pypy. Cheers, fijal
_______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
