On Sun, Jul 25, 2010 at 3:30 AM, Guido van Rossum <gu...@python.org> wrote: > On Fri, Jul 23, 2010 at 4:20 PM, Alexander Belopolsky > <alexander.belopol...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/archive%40mail-archive.com