On 7 September 2013 19:06, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sat, 7 Sep 2013 08:57:07 +0200 > Xavier Morel <python-...@masklinn.net> wrote: >> >> On 2013-09-07, at 05:40 , Jesus Cea wrote: >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On 06/09/13 20:33, Antoine Pitrou wrote: >> >> On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea <j...@jcea.es> wrote: >> >>> >> >>> It is intrusive. Yes. I think it must be, by its own nature. >> >>> Probably room for improvement and code transparency. But... are >> >>> Python-DEVs interested in the project?. That is the point :) >> >> >> >> As a concrete data point: - here are Dave's modifications to >> >> ceval.c for systemtap: >> >> http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here >> >> are your modifications to ceval.c for dtrace: >> >> http://bugs.python.org/review/13405/diff/6151/Python/ceval.c >> > >> > Unfair, because that code is not doing the same thing. >> > >> > Most of the extra complexity is there to deal with DTRACE ability to >> > provide meaningful stackframes, with Python code instead of CPython >> > evaluation loop. This is kind of magical. >> >> Antoine will correct me if I'm wrong, but I believe his point is less >> about the complexity of dtrace provision and more about how much of it >> lives in ceval.c: the systemtap provision also takes quite a bit of >> code, but almost all of that code is extracted into a separate file and >> only a pair of calls live in ceval.c > > Yes, that's exactly my point. There can be an arbitrarily complex > ceval-dtrace.h for all I care :-) > > Thanks for the examples, by the way.
Yep, complex stuff inline should be abstracted out so it doesn't affect the code flow for those of us that don't care :) Between Jesus, the Mac OS X using core devs and the Solaris and Mac OS X buildbots it should be a maintainable addition. However, it seems worthwhile to write up a short PEP (akin to the tracemalloc PEP) to scope out the suggestion. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
