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
-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
[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" t
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" t
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"
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
__
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 inst
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 difference
-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
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 ge
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 sp
[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 .
The relative speed of approaches changes across Python releases too.
For example, modu
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 that
[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 loo
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:
> >>>
> >>> d
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):
r
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 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_
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 - Zope-Dev@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
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 2.7.6'
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 fi
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
[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 pa
-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)
>> r
25 matches
Mail list logo
