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:
]
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
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
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
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
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
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
