[Zope-dev] hasattr implementation for Zope?

2005-05-27 Thread Chris Withers
Dieter Maurer wrote: I strongly argue against it. Fix hasattr in the Zope context, instead! _marker = [] def hasattr(obj, attr, marker): a = getattr(obj, attr, _marker) return a is not _marker import __builtin__ __builtin__.hasattr = hasattr Easy

Re: [Zope-dev] hasattr implementation for Zope?

2005-05-27 Thread Paul Winkler
On Fri, May 27, 2005 at 08:53:54AM +0100, Chris Withers wrote: Anyone think putting this in Zope core is a good idea? If so, where should it go? Any potential performance implications people can think of? fwiw, tonight I ran some quick request-per-second tests (using ab -n 100 -c 10) on a

Re: [Zope-dev] RAMcache and container vs. context

2005-05-27 Thread Stefan H. Holek
A TALES expression may be prohibitively expensive in any case, no matter how simple it is kept. Please make sure to do some comparative profiling. Cache keys are recomputed on every call of the script, AFAICS. The thought of doing this in restricted Python makes my skin crawl. Stefan

[Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Dieter Maurer wrote: I strongly argue against it. Fix hasattr in the Zope context, instead! _marker = [] def hasattr(obj, attr, marker): a = getattr(obj, attr, _marker) return a is not _marker

[Zope-dev] Re: [Interested?] New use for Zope+CMF+Archetypes -- startup time improvements

2005-05-27 Thread Dieter Maurer
Dieter Maurer wrote at 2005-5-13 19:26 +0200: ... high Zope startup time ... To overcome this obstacle, we tweaked Zope and fixed Python's import mechanism such that Zope now starts either out of a ZIP archive or as a frozen application. ... In more details, we did: * implement a package for

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Tim Peters
[Tres Seaver] [...] - -1. Python's 'hasattr' semantics are *broken by definition*, and will never be fixed (because of backward compatibility). Non-Zope Python programmers will *not* expect or want exceptions raised from 'hasattr'. As a local patch, this isn't too bad (one could even

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Jim Fulton
Tim Peters wrote: [Tres Seaver] [...] - -1. Python's 'hasattr' semantics are *broken by definition*, and will never be fixed (because of backward compatibility). Non-Zope Python programmers will *not* expect or want exceptions raised from 'hasattr'. As a local patch, this isn't too bad (one

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Paul Winkler
On Fri, May 27, 2005 at 09:25:58AM -0400, Jim Fulton wrote: Tim Peters wrote: OTOH, defining importing a utility function-- say, safehasattr() --would make it all explicit. That's what ZODB does. OK. (BTW, I just went grepping for this safehasattr() in zope 2.7.6's ZODB and didn't find

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Jim Fulton
Paul Winkler wrote: On Fri, May 27, 2005 at 09:25:58AM -0400, Jim Fulton wrote: Tim Peters wrote: OTOH, defining importing a utility function-- say, safehasattr() --would make it all explicit. That's what ZODB does. OK. (BTW, I just went grepping for this safehasattr() in zope

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Tim Peters
[Tim Peters] OTOH, defining importing a utility function-- say, safehasattr() --would make it all explicit. That's what ZODB does. [Paul Winkler] OK. (BTW, I just went grepping for this safehasattr() in zope 2.7.6's ZODB and didn't find anything. What's it called?) No such thing in ZODB

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Paul Winkler
On Fri, May 27, 2005 at 11:52:10AM -0400, Tim Peters wrote: Spend an hour analyzing each one 0.9 wink. Let's compromise. I'll spend 0.9 hours analyzing one of them. ;-) -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist -

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Paul Winkler
On Fri, May 27, 2005 at 11:49:03AM -0400, Jim Fulton wrote: BTW, I prefer to code things like this in the following way: def safe_hasattr(): marker = object() def safe_hasattr(obj, attr): return getattr(obj, attr, marker) is not marker return safe_hasattr

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Paul Winkler
On Fri, May 27, 2005 at 12:08:55PM -0400, Paul Winkler wrote: On Fri, May 27, 2005 at 11:49:03AM -0400, Jim Fulton wrote: BTW, I prefer to code things like this in the following way: def safe_hasattr(): marker = object() def safe_hasattr(obj, attr): return

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Jim Fulton
Paul Winkler wrote: On Fri, May 27, 2005 at 12:08:55PM -0400, Paul Winkler wrote: On Fri, May 27, 2005 at 11:49:03AM -0400, Jim Fulton wrote: BTW, I prefer to code things like this in the following way: def safe_hasattr(): marker = object() def safe_hasattr(obj, attr):

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Paul Winkler
On Fri, May 27, 2005 at 01:10:29PM -0400, Jim Fulton wrote: Paul Winkler wrote: On Fri, May 27, 2005 at 12:08:55PM -0400, Paul Winkler wrote: On Fri, May 27, 2005 at 11:49:03AM -0400, Jim Fulton wrote: BTW, I prefer to code things like this in the following way: def safe_hasattr():

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Tim Peters
[Paul Winkler] But of course we don't do it because accessing globals in a method that might be looped over is slow. Which, hopefully, will become a non-issue some day (PEP 267, 268, 280). [Jim Fulton] Note that in my version above, marker is a local rather than a global and gets looked up

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Jim Fulton
This is amazing. Really amazing. I stand corrected. Jim Tim Peters wrote: [Paul Winkler] But of course we don't do it because accessing globals in a method that might be looped over is slow. Which, hopefully, will become a non-issue some day (PEP 267, 268, 280). [Jim Fulton] Note

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Tim Peters
[Jim Fulton, on cell dereferencing's (lack of) speed] This is amazing. Really amazing. I stand corrected. Well, there's no mystery if you look at LOAD_FAST and LOAD_DEREF in ceval.c; LOAD_DEREF is slower wink. The relative speed of approaches changes across Python releases too. For example,

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Sidnei da Silva
On Fri, May 27, 2005 at 01:49:00PM -0400, Tim Peters wrote: | Under WinXP Python 2.4.1, the global trick (lookup3) is consistently | fastest, and the lexical scope trick (lookup2) is consistently | slowest; this is typical output across 3 runs: Humm... May not be a surprise for you, but in one

Re: [Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Paul Winkler
On Fri, May 27, 2005 at 01:49:00PM -0400, Tim Peters wrote: Nope, it's a cell reference to an enclosing scope, and gets looked up at cell-dereference speed. In my experience, that's generally a bit slower than accessing a module global. That may have to do with a quirk of MSVC's code

[Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: Vewy strange -- it looks as though OS-level caching matters here: $ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type help, copyright, credits or license for more information. $

[Zope-dev] Re: hasattr implementation for Zope?

2005-05-27 Thread Tim Peters
We're getting the usual timing results here: it's a cross-platform, cross-release crapshoot. Aiming at (just) a few percent really is worthless -- modern processors and OSes are too complex to out-think uniformly in the small, and even if Python variability didn't contribute to the differences.