Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
On Monday 04 March 2002 06:41 pm, Anthony Baxter allegedly wrote: > >>> "Brian Lloyd" wrote > > 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] I think particularly promiscuous monkey patches should be called "bonobo patches" 8^) /---\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association [EMAIL PROTECTED] \---/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
Not a bad idea. On that note, can we add an API to add Control_Panel icons please? Adrian... -- The difficulty of tactical maneuvering consists in turning the devious into the direct, and misfortune into gain. - Sun Tzu - Original Message - From: "Toby Dickenson" <[EMAIL PROTECTED]> To: "Brian Lloyd" <[EMAIL PROTECTED]> Cc: "seb bacon" <[EMAIL PROTECTED]>; "Chris Withers" <[EMAIL PROTECTED]>; "Richard Jones" <[EMAIL PROTECTED]>; "Casey Duncan" <[EMAIL PROTECTED]>; "Anthony Baxter" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, March 05, 2002 11:00 AM Subject: Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning) On Mon, 4 Mar 2002 15:20:58 -0500, "Brian Lloyd" <[EMAIL PROTECTED]> wrote: > I can attest that the only thing worse than confusing >code is _invisible_ code. The main page of the Control_Panel already displays a fairly long list of name/value pairs describing the state of the zope installation: Zope Version, INSTANCE_HOME, etc. Maybe Products should be able to include 'headline news' which also gets displayed there. ? Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
On Mon, 4 Mar 2002 15:20:58 -0500, "Brian Lloyd" <[EMAIL PROTECTED]> wrote: > I can attest that the only thing worse than confusing >code is _invisible_ code. The main page of the Control_Panel already displays a fairly long list of name/value pairs describing the state of the zope installation: Zope Version, INSTANCE_HOME, etc. Maybe Products should be able to include 'headline news' which also gets displayed there. ? Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
On Tue, 5 Mar 2002 07:20, Brian Lloyd wrote: > Seb wrote: > > Pros - a tiny performance gain > > Cons - unpredictable interaction with future products; not a well-known > > method of distributing products; not easily discoverable > > 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 doesn't really address the concern I have with regard to the con given above. The main reason is that the call profiler's monkeypatching is done potentially many times, and it performs an unpatch as well as a patch. This muckery can potentially really stuff over other components that also monkeypatch the same methods. Especially if they _also_ perform unpatching. I'm not sure the consentual monkeypatch approach really solves this issue... and if the product has to be modified to make it register itself with the profiler, why not just have it include the (very simple) calls to the profiler instead? Richard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
>>> "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 <[EMAIL PROTECTED]> 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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
With respect to the overhead of inserting things into modules in the source code, Fred Drake (I think!) pointed out to me that constructs in the form if __debug__: ... are automatically removed by the parser when Python is run with the -O flag. Note that I am *not* sure how Zope performs when run with Python -O. However, assuming it does run OK, then it makes sense to put all sorts of conditional things into code which are disabled for performance when -O is passed on the command line to Python. Also note that I guarantee Zope will not run with Python -OO, as this removes doc strings, which the Publisher relies upon. At the time, I was pushing more for a slightly more complex form of run time diagnostic control without the overhead of continuous symbol lookup, e.g. ifcondition(bitmask): such that either all the bits in the bitmask were "enabled" in the current debugging context, or at least some of them were. Then again, I effectively want exits in Python's ceval.c at various locations to be able to do "magic" without the burden of more interpretation. For instance, there are actually some clever things you can do with the new C level profiler, but 'stealing' the profiler to do other magic is not really the right approach. -- Matt Kromer Zope Corporation http://www.zope.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
> 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. > > Think of this as "consentual" monkey-patching (hmm... may have to > change this metaphor soon!). 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. > > Thoughts? Bingo! seb ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
> Indeed. However, I was being a bit glib with my example, and didn't > explain my point properly: that performance issues should be subordinate > to good design. Therefore, I suspect MonkeyPatching is bad: > > Pros - a tiny performance gain > Cons - unpredictable interaction with future products; not a well-known > method of distributing products; not easily discoverable > > But perhaps my 'cons' are misplaced? Mostly, I'm uneasy that someone > looking at ZPublisher code would have no way of knowing that > CallProfiler hooks into it if it were monkeypatched. Monkey-patching should be thought of as a last resort, when it absolutely-positively-has-to-get-there-overnight (security hotfixes, etc.), for exactly the cons described above. Speaking as one who has been bitten by this sort of thing before (with the bite marks to prove it!), I can attest that the only thing worse than confusing code is _invisible_ code. That said -- I think that Richard's approach is quite powerful, and I think that there is a middle ground here. I think that the call profiler could be brought into the core with minimal changes and without being "invisible" or seeming to promote monkey-patching. 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. Think of this as "consentual" monkey-patching (hmm... may have to change this metaphor soon!). 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. Thoughts? Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)
On Mon, 2002-03-04 at 11:23, Chris Withers wrote: > seb bacon wrote: > > > > http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/4084B02199CC6AFB > > > > (to save the bother of following the link, that's the thread from about > > a month ago regarding evidence suggesting ZPT may be *twice* as slow as > > DTML) > > Yup. And I'm a pretty strong advocate that ZPT should be speeded up a lot. Indeed. However, I was being a bit glib with my example, and didn't explain my point properly: that performance issues should be subordinate to good design. Therefore, I suspect MonkeyPatching is bad: Pros - a tiny performance gain Cons - unpredictable interaction with future products; not a well-known method of distributing products; not easily discoverable But perhaps my 'cons' are misplaced? Mostly, I'm uneasy that someone looking at ZPublisher code would have no way of knowing that CallProfiler hooks into it if it were monkeypatched. seb seb ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
