Re: [Zope-dev] Re: hasattr implementation for Zope?
-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 of a patched 'hasattr', but >>should use the 3 argument getattr instead. > > > I think this is *very* bad! > > It is quite difficult to get the "hasattr" emulation via > "getattr" correct. > > If you do not like a modified "__builtin__.hasattr" (which I can understand), > then provide at least a "__builtin__.zhasattr" (or similarly named) available > in restricted code and strongly recommend in the documentation to use this > variant of "hasattr" for any Zope/ZODB object. As Tim notes, if we aren't replacing the builtin, then we could equally well recommend the following pattern: # in ZODB.utils def safe_hasattr(obj, name, _marker=object()): """Make sure we don't mask exceptions like hasattr(). We don't want exceptions other than AttributeError to be masked, since that too often masks other programming errors. Three-argument getattr() doesn't mask those, so we use that to implement our own hasattr() replacement. """ return getattr(obj, name, _marker) is not _marker & in any module which uses hasattr from ZODB.utils import safe_hasattr # was: if hasattr(object, 'attribute'): if safe_hasattr(object, 'attribute'): 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!). We would then (as you note) need to ensure that we made it available to restricted code. For that casee, we might need a variant of it which used 'guarded_getattr' (but I'm not sure about that). Tres. - -- === Tres Seaver [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCmJ2q+gerLs4ltQ4RAgBHAKC41yH93Xef8Zy0FgEXkauPevp/MACfdOdg d7rWGDewxLvq2+CANiNR6v4= =HQMV -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: hasattr implementation for Zope?
[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 function's local namespace > should be faster than any other variable access. It is, although module-global lookup is often much faster now than Python old-timers "know" it is : the critical successful path thru the dict lookup code for a dict keyed by interned strings is, in the absence of collisions, _almost_ as lean as an indexed array access now. The primary difference in speed remaining is that the dict lookup endures an extra C-level function call. I explained a relevant difference last time: lookup1 has the additional expense of initializing an additional local variable. That's what a default argument becomes, and nothing happens for free. Let's time this effect "in isolation": """ from itertools import repeat from time import clock as now def with(default=5): pass def without(): pass for dummy in range(3): for f in with, without: start = now() for dummy in repeat(None, 100): f() finish = now() print "%-8s %.6g" % (f.__name__, finish - start) """ and typical output: with 0.374435 without 0.338555 with 0.370469 without 0.339791 with 0.372165 without 0.337355 So adding a default argument indeed has a measurable cost (although ~0.03 seconds across a million calls is nothing to fret about!). Note that the difference between lookup1 and lookup3 was less than that on this box, reflecting that the lookup _inside_ lookup1 goes faster than the lookup inside lookup3, partly cancelling lookup1's higher call overhead; the difference in call overhead is greater than the difference in lookup speed, so lookup1 ends up a net loser. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: hasattr implementation for Zope?
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 the function's local namespace should be faster than any other variable access. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RAMcache and container vs. context
Stefan H. Holek wrote at 2005-5-27 10:59 +0100: >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. But "TALES" expressions need not necessarily be restricted (see my "TrustedExecutables"). Though, I did not think about the security inplications when we would use unrestricted TALES expressions for a cache manager. It would probably be a bad idea. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: hasattr implementation for Zope?
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 available there. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: hasattr implementation for Zope?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: hasattr implementation for Zope?
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. I think this is *very* bad! It is quite difficult to get the "hasattr" emulation via "getattr" correct. If you do not like a modified "__builtin__.hasattr" (which I can understand), then provide at least a "__builtin__.zhasattr" (or similarly named) available in restricted code and strongly recommend in the documentation to use this variant of "hasattr" for any Zope/ZODB object. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
