Antoine Pitrou <pit...@free.fr> added the comment: > So, yes. The code is intrusive. The code deals with a lot of internal > machinery (PEP393 support in the ustack helper was quite difficult). > It is going to break from time to time, sure. At the same time, I am > committed to support it. And even if it is dropped in 3.4, no Python > program will be affected.
To ease the concerns, I think you should make it so that dtrace-specific code gets out of the way as much as possible. I suggest you create a Python/ceval-dtrace.h header and put most dtrace-specific code from ceval.c there. Its inclusion should be conditional on WITH_DTRACE so that other core devs can ignore its presence. A couple other comments: - in the makefile, DTRACEOBJS is inconsistent with DTRACE_STATIC and LIBRARY_OBJS. You should make it DTRACE_OBJS. - please add comments at the top of whatever header files you add, to make it clear that they are dtrace-specific. Mentions of "ustack helper" are a bit too specific to be helpful. - some code lacks error checking, e.g. when calling PyUnicode_AsUTF8. - is co_linenos ever freed or is it a memory leak? - your indices and offsets should be Py_ssize_t, not int - is an empty dtrace module really needed? a flag variable in the sys module should be enough - as you can see the Makefile uses "-rm -f", you should probably do the same instead of "rm -f" - you have a rather strange "if true" in your configure.in additions Thanks in advance. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13405> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
