Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)

2002-03-05 Thread Toby Dickenson

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)

2002-03-05 Thread Adrian Hungate

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)

2002-03-05 Thread Casey Duncan

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)

2002-03-04 Thread Brian Lloyd

 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 )



Re: [Zope-dev] MonkeyPatching in the Core (was: Zope 2.6 planning)

2002-03-04 Thread seb bacon

 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)

2002-03-04 Thread Matthew T. Kromer

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)

2002-03-04 Thread Richard Jones

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)

2002-03-04 Thread Anthony Baxter


 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 )