Tres Seaver wrote at 2005-5-28 12:34 -0400:
...
The spelling, of course, would be up for endless argument. ;) Perhaps
we could call it 'persistent_hasattr', and then let folks alias it at
import time as they wish (even to 'hasattr', but not in the core!).
The spelling is not my major concern.
Tres Seaver wrote at 2005-5-27 08:22 -0400:
...
As a local patch, this isn't too bad (one could even package it as a
do-nothing-after-initialization product). However, no redistributed
product code should rely on the presence of a patched 'hasattr', but
should use the 3 argument getattr instead.
Jim Fulton wrote at 2005-5-27 11:49 -0400:
...
I'm sure this was an unintentional non-acceptance. It would be
a lot easier if Dieter became a contributor and checked this in
himself.
You know the unqualified indemnification clause concerning
patents it preventing me...
--
Dieter
Paul Winkler wrote at 2005-5-27 11:02 -0400:
...
def safe_hasattr(obj, attr, acquired=True, _marker=[]):
if not acquired:
obj = aq_inner(aq_explicit(obj))
This should be obj = aq_base(obj).
The aq_explicit(aq_inner(...)) dance is only necessary in
untrusted code as aq_base is not
Tim Peters wrote at 2005-5-27 13:49 -0400:
...
def lookup1(arg, _marker=object()):
return _marker
...
_marker = object()
def lookup3(arg):
return _marker
...
lookup1 0.427597
lookup3 0.404399
Do you understand why lookup3 is faster than lookup1?
I had the impression that access to
[Tim Peters]
def lookup1(arg, _marker=object()):
return _marker
...
_marker = object()
def lookup3(arg):
return _marker
...
lookup1 0.427597
lookup3 0.404399
[Dieter Maurer]
Do you understand why lookup3 is faster than lookup1?
I had the impression that access to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Maurer wrote:
Tres Seaver wrote at 2005-5-27 08:22 -0400:
...
As a local patch, this isn't too bad (one could even package it as a
do-nothing-after-initialization product). However, no redistributed
product code should rely on the presence
[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
22 matches
Mail list logo
