"Martin v. Löwis"
martin at v.loewis.de
Mon Nov 21 22:29:55 CET 2005
Armin Rigo wrote:
> I see no incremental way of fixing some of the downsides of hotshot,
> like its huge log file size and loading time.
I haven't looked into the details myself, but it appears that some
google-summer-of-code contributor has found some way of fixing it.
> I doubt people often find
> the motivation to dig into this large orphaned piece of software.
As Fredrik says: this sounds like the CADT model. The code isn't really
orphaned - it's just that it isn't used much. Contributions to this
code certainly would still be accepted (and happily so).
So essentially: fixing bugs isn't fun, but rewriting it from scratch is.
> I'm not even sure in this case why
> we are arguing
That's pretty obvious to me: because some people are shy of letting
version 0.8 of the old software be replaced with version 0.8 of the
new software, which is then replaced with version 0.8 of the next
Instead, we should stick to what we have, and improve it.
Now, it might be that in this specific case, replacing the library
really is the right thing to do. It would be if:
1.it has improvements over the current library already
(certified by users other than the authors), AND
2.it has no drawbacks over the current library, AND
3.there is some clear indication that it will get better maintenance
than the previous library.
I'm not certain lsprof has properties 2 and 3; property 1, so far,
is only asserted by the library author himself.
Perhaps it is true what Fredrik Lundh says: there shouldn't be a
profiler in the standard library at all.
More information about the Python-Dev