Re: [Python-Dev] Python profiler and other tools
I am changing the subject from "http://bugs.python.org/issue231540," because if there was a prize for a non-descriptive subject, OP would win it. There must be a good reason why traditional software development tools such as debugger, profiler and coverage are mostly neglected in python. Terry and I have recently discovered that the trace (coverage) module does not have any unit tests [1] and pretty much does not work in 3.x. [2] One of the recently fixed trace module problems [3] is likely affecting profile module as well. I tried to figure out who works on profile to add them to the nosy list and could not find anyone. I seem to remember someone suggesting that python's dynamic nature makes traditional development tools unnecessary. A print statement is the only debugging tool that you need. There may be some truth to it, but in this case, python should not distribute these tools. I am personally in the opposite camp: I love pdb and I am a big believer in profiling and coverage testing. I have entered myself as a maintainer for the trace module which is the simplest of the three, but I would like to learn from developers of pdb and profile on a range of overlapping issues. [1] http://bugs.python.org/issue9315 [2] http://bugs.python.org/issue9317 [3] http://bugs.python.org/issue9323 On Fri, Jul 23, 2010 at 6:26 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Is there any money to pay for the forthcoming 10th birthday party for this issue? Is the OP still alive?
Kindest regards.
Mark Lawrence.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexander.belopolsky%40gma...
On Fri, Jul 23, 2010 at 4:20 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
There must be a good reason why traditional software development tools such as debugger, profiler and coverage are mostly neglected in python.
Most such tools are probably better developed outside the standard library. There are many reasons for that, but I would guess that it mostly has to do with very different development cycles for tools. Tool development usually goes in quick bursts (driven by urgent needs and perhaps improving tool developer skills) unrelated to the stdlib release cycle (and releasing the stdlib separately won't make much of a difference). Also tools often have rough edges, and the stdlib (except for the stuff added before 1995 or so :-) has a high perfectionism standard. -- --Guido van Rossum (python.org/~guido)
On Sun, Jul 25, 2010 at 3:30 AM, Guido van Rossum <guido@python.org> wrote:
On Fri, Jul 23, 2010 at 4:20 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
There must be a good reason why traditional software development tools such as debugger, profiler and coverage are mostly neglected in python.
Most such tools are probably better developed outside the standard library. There are many reasons for that, but I would guess that it mostly has to do with very different development cycles for tools. Tool development usually goes in quick bursts (driven by urgent needs and perhaps improving tool developer skills) unrelated to the stdlib release cycle (and releasing the stdlib separately won't make much of a difference). Also tools often have rough edges, and the stdlib (except for the stuff added before 1995 or so :-) has a high perfectionism standard.
Part of me agrees with you regarding the generally different tool lifecycle, but another part says we need these tools in the standard library or we risk inadvertently breaking the hooks they would still rely on, even as third party projects. I suspect a major factor here relates to the degree of unit test coverage for these components - for areas that aren't of direct interest to me, I'll still deal with it if something I do breaks that code's unit tests, but if the tests don't start failing I'll never even think to check for an incompatibility. (e.g. I seem to recall line tracing for with statements and/or generator expressions being broken for a while before we fixed it) PEP 306 (the one about changing the grammar) and PEP 339 (which includes a short section on changing the bytecode definition) may also be missing some steps to make sure that any syntax and opcode changes are correctly covered by the disassembly, debugging, profiling and tracing tests. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Jul 24, 2010 at 8:29 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Sun, Jul 25, 2010 at 3:30 AM, Guido van Rossum <guido@python.org> wrote:
On Fri, Jul 23, 2010 at 4:20 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
There must be a good reason why traditional software development tools such as debugger, profiler and coverage are mostly neglected in python.
Most such tools are probably better developed outside the standard library. There are many reasons for that, but I would guess that it mostly has to do with very different development cycles for tools. Tool development usually goes in quick bursts (driven by urgent needs and perhaps improving tool developer skills) unrelated to the stdlib release cycle (and releasing the stdlib separately won't make much of a difference). Also tools often have rough edges, and the stdlib (except for the stuff added before 1995 or so :-) has a high perfectionism standard.
Part of me agrees with you regarding the generally different tool lifecycle, but another part says we need these tools in the standard library or we risk inadvertently breaking the hooks they would still rely on, even as third party projects.
The hooks need to be exercised by unittests, for sure. Hooks are APIs with a contract and a promise of stability (though sometimes it's complicated).
I suspect a major factor here relates to the degree of unit test coverage for these components - for areas that aren't of direct interest to me, I'll still deal with it if something I do breaks that code's unit tests, but if the tests don't start failing I'll never even think to check for an incompatibility. (e.g. I seem to recall line tracing for with statements and/or generator expressions being broken for a while before we fixed it)
Sure, but I don't see how the presence of a tracing tool in the stdlib would have helped -- in fact, there's pdb which does use the tracing hooks, but that was a new use case and nobody thought of checking it.
PEP 306 (the one about changing the grammar) and PEP 339 (which includes a short section on changing the bytecode definition) may also be missing some steps to make sure that any syntax and opcode changes are correctly covered by the disassembly, debugging, profiling and tracing tests.
That's a good idea regardless. -- --Guido van Rossum (python.org/~guido)
Part of me agrees with you regarding the generally different tool lifecycle, but another part says we need these tools in the standard library or we risk inadvertently breaking the hooks they would still rely on, even as third party projects.
I suspect a major factor here relates to the degree of unit test coverage for these components - for areas that aren't of direct interest to me, I'll still deal with it if something I do breaks that code's unit tests, but if the tests don't start failing I'll never even think to check for an incompatibility. (e.g. I seem to recall line tracing for with statements and/or generator expressions being broken for a while before we fixed it)
It is at best entertaining to ponder about reasons here; I doubt anything productive can come out of such a discussion. It may be fun posting a message to a ten-year-old issue saying "ACT NOW (you sluggards)", but I question that this will, on average, improve things. Likewise, speculating that tool support is deliberately ignored probably won't improve things (specifically *not* responding to Nick here). On the other hand, posting actual patches that fix actual bugs can make a lot of a difference. Also, having a maintainer who is willing to look into these patches and accept the good ones will make a lot of a difference. Regards, Martin
On Sun, Jul 25, 2010 at 1:22 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote: ..
It is at best entertaining to ponder about reasons here; I doubt anything productive can come out of such a discussion.
I disagree. Depending on the reasons for the relative lack of attention to these components, several alternative actions can be taken to improve the situation. Let's focus on the trace module because it is the simplest and in my opinion the most neglected of the three. Guido suggested that a tool like this is best developed outside of stdlib and python-dev should focus on providing stable interfaces such as sys.settrace to third party projects. On one hand, I would agree that it is better not to distribute the trace module at all than to distribute a broken implementation. (Quality of coverage tools is particularly important now when many developers try to improve up their test coverage before or during transition to 3.x.) On the other hand, using sys.settrace interface requires knowledge of the frame object structure which AFAICT is an implementation detail and may change from version to version. I think stdlib should expose a more abstract tracing API such as one implemented by the trace module which would hide frame object details from the user and give direct access to the data extracted from the frames such as file names and line numbers. A higher level module within stdlib can take advantage of implementation details and not be burdened by having to support multiple releases as long as its own user facing API is stable.
It may be fun posting a message to a ten-year-old issue saying "ACT NOW (you sluggards)", but I question that this will, on average, improve things. Likewise, speculating that tool support is deliberately ignored probably won't improve things (specifically *not* responding to Nick here).
I assume this is directed at Mark Lawrence even though I made the top post under this subject. While I expressed my own share of criticism of Mark's ways, I do believe that what he is doing is extremely valuable. I did not expect such an outcome, but Mark had a lot of success closing the issues that simply slipped under the radar, but were resolved or close to resolution in every other respect. He is apparently putting a lot of his volunteer hours into this work and this is reason enough to overlook occasional rants or poor choice of words. Mark's breadth-first approach to the tracker is unique and does not work for a lot of issues, but at the same time it does work maybe 10-20% of the time and as long as Mark himself does not get discouraged by the low success rate and learns how to communicate more effectively, I think his work will continue benefiting python.
On the other hand, posting actual patches that fix actual bugs can make a lot of a difference. Also, having a maintainer who is willing to look into these patches and accept the good ones will make a lot of a difference.
With respect to the trace module, I started both of these things already, but I would really like to hear feedback from people interested in the future of pdb and profile modules as well.
On 25/07/2010 19:34, Alexander Belopolsky wrote:
[snip...]
On the other hand, posting actual patches that fix actual bugs can make a lot of a difference. Also, having a maintainer who is willing to look into these patches and accept the good ones will make a lot of a difference.
With respect to the trace module, I started both of these things already, but I would really like to hear feedback from people interested in the future of pdb and profile modules as well.
Antonio Cuni demoed some *great* improvements to the pdb module at EuroPython. A project called pdb++ http://codespeak.net/svn/user/antocuni/hack/pdb.py Among its improvements it includes the ability to debug through generator frames, which pdb can't. It would be great to see some of these fixes folded back into the standard library version. All the best, Michael Foord
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Jul 25, 2010, at 11:38 AM, Michael Foord wrote:
On 25/07/2010 19:34, Alexander Belopolsky wrote:
[snip...]
On the other hand, posting actual patches that fix actual bugs can make a lot of a difference. Also, having a maintainer who is willing to look into these patches and accept the good ones will make a lot of a difference.
With respect to the trace module, I started both of these things already, but I would really like to hear feedback from people interested in the future of pdb and profile modules as well.
Antonio Cuni demoed some *great* improvements to the pdb module at EuroPython. A project called pdb++
http://codespeak.net/svn/user/antocuni/hack/pdb.py
Among its improvements it includes the ability to debug through generator frames, which pdb can't. It would be great to see some of these fixes folded back into the standard library version.
+1 Raymond
On Sun, Jul 25, 2010 at 11:53 AM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Jul 25, 2010, at 11:38 AM, Michael Foord wrote:
Antonio Cuni demoed some *great* improvements to the pdb module at EuroPython. A project called pdb++
http://codespeak.net/svn/user/antocuni/hack/pdb.py
Among its improvements it includes the ability to debug through generator frames, which pdb can't. It would be great to see some of these fixes folded back into the standard library version.
+1
+1 on adding tracing through generators. Not so much about the other pdb++ features that were demoed. While I liked the demo at EuroPython (and applauded), in general I am wary of adding this kind of UI cleverness to the stdlib -- things like the (seemingly curses-based) updating of the listing in-line are usually pretty fragile. Also the development cycle of a tool like this is likely 1-2 orders of magnitude over that of the stdlib. (For this reason I also think it's right that ipython is still a 3rd party tool). -- --Guido van Rossum (python.org/~guido)
participants (6)
-
"Martin v. Löwis" -
Alexander Belopolsky -
Guido van Rossum -
Michael Foord -
Nick Coghlan -
Raymond Hettinger