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
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
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
-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
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
[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
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
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
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
[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
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 -
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
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
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):
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():
[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
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
[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,
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
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
-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.
$
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.
22 matches
Mail list logo