"Brian Lloyd" wrote What if, instead of the static list of callable info that the CP currently uses, Zope objects could register themselves as profilable? We would then make sure that the object types that CP handles now register themselves, but other products that we don't know (or have to know) about could register themselves too if they wanted.
This would resolve the problems, yes. It's a nice approach to take, and it also allows the object to register a different method to be patched.
Think of this as "consentual" monkey-patching (hmm... may have to change this metaphor soon!).
Call it "gorilla-patching" - it's like monkey-patching.[1]
The products have to take some explicit action to be profilable, so it is not invisible in the code of the product. The hooks will continue to installed as-needed, so there is no performance issue.
This would suggest that the CallProfiler shouldn't be an add-on product, then, but installed in lib/python ? What's the best approach there? Rich didn't get any response on zope-coders about this... Anthony [1] Seagoon: Here! Have a gorilla. Eccles: Oh! Thanks. Grams: [Two gorillas fighting, or if you can't get that, lions.] Eccles: Oww! Oww! Ooh! Oww! Hey! These gorillas are strong. Here! Have one of my monkeys -- they're milder. -- http://www.residents.com/Goons/napoleon.piano.html -- Anthony Baxter <anthony@interlink.com.au> It's never to late to have a happy childhood. Seagoon: Here! Have a gorilla. Eccles: Oh! Thanks. Grams: [Two gorillas fighting, or if you can't get that, lions.] Eccles: Oww! Oww! Ooh! Oww! Hey! These gorillas are strong. Here! Have one of my monkeys -- they're milder.