From: Stephen Hansen on 3 Apr 2010 15:03
On 2010-04-02 20:24:46 -0700, Patrick Maupin said:
> On Apr 2, 10:11�pm, Stephen Hansen <apt.shan...(a)gmail.invalid> wrote:
>> I don't know if properties are really faster or slower then a
>> __getattr__, but I find them a lot cleaner if I want to delay some
>> calculation until needed like that.
> Well, the relative speed of properties vs. __getattr__ can become
> irrelevant in at least two ways:
> 1) If the __getattr__ only calculates the value one time and then
> stuffs it into the instance dictionary, now you are really comparing
> the relative speed of properties vs. lookup of an attribute in the
> instance dict. If you're at all concerned about speed, I think there
> is a clear winner here.
I concede it would probably be notably faster, but there's a big
difference between "at all concerned about speed" and "optimizing a
The speed difference between direct attribute lookup and properties may
be notable, but that doesn't make a clear winner here. Now that I have
(with either method) optimized the expensive value-calculation
operation such that it only happens on-demand and once, I now have to
weigh further optimization.
Is the difference in speed between a standard attribute lookup and a
property fetch worth losing the clarity the property brings over the
__getattr__ solution, especially considering the __getattr__ creates a
fuzzy 'sometimes this code is responsible, othertimes the dict is'
situation that someone may down the road miss in maintenance?
For me, usually not-- unless profiling pushes me to reconsider. But
everyone makes these calls differently.
> 2) There is a single __getattr__ function, vs. one property for every
> attribute that needs a property. In cases where you can somehow
> easily compute the attribute names as well as the attribute values,
> __getattr__ can be a *lot* less code than defining dozens of
I don't really mind a lot of properties, if they're simple. Then again,
I often prefer regular ol' attributes where possible :) However, if I'm
doing a dispatching sort of mechanism, or a situation where the "name"
isn't something static, set in stone or pre-defined-- then certainly,
__getattr__ is a fine solution. I don't mind it where its the clearest
way to accomplish a goal.
.... p.s: change the ".invalid" to ".com" in email address to reply privately.
From: John Nagle on 4 Apr 2010 14:57
> When coding C I have often found static local variables useful for
> doing once-only run-time initializations.
If you want functions with state, use an object. That's what they're
for. Don't muck with the internal representation of functions.
From: Patrick Maupin on 4 Apr 2010 16:35
On Apr 4, 1:57 pm, John Nagle <na...(a)animats.com> wrote:
> If you want functions with state, use an object. That's what they're
> for. Don't muck with the internal representation of functions.
While "Don't muck with the internal representation of functions" is
excellent advice over 99% of the time, it is also true that it is
often possible, sometimes even encouraged, to have "functions with
This is done without "mucking" and without explicitly declaring a
class or a class instance. See, e.g. closures and generator
From: Lee Harr on 5 Apr 2010 17:04
> Another approach would be to stuff the static values in the function's
That's how I did it when I wanted something similar.
I created this decorator:
��� Used to create a decorator function that will add an
��� attribute to a function and initialize it.
��� ... def bar():
��� ...���� print bar.foo
��� ...���� bar.foo += 1
��� def decorator(f):
������� return f
��� return decorator
Hotmail: Trusted email with Microsoft�s powerful SPAM protection.
From: Ethan Furman on 5 Apr 2010 19:50
Ethan Furman wrote:
> Steven D'Aprano wrote:
>> On Fri, 02 Apr 2010 19:48:59 -0700, Ethan Furman wrote:
>>>> The heuristic I use is, if I expect the try block to raise an exception
>>>> more than about one time in ten, I change to an explicit test. In this
>>>> case, since the exception should only be raised once, and then never
>>>> again, I would use a try...except block.
>>> That was my reasoning as well, but when I timed it for one million runs
>>> (so 1 instantiation, 999,999 simple calls), the __getattr__ time was .5
>>> seconds, the try...execpt block was .6; at ten million it was 5 and 6.
>> Care to share your timing code? Not that I don't trust your results,
>> but timings are very sensitive to the exact thing you do, and I'd like
>> to see what that is.
> Happy to do so -- if I made a mistake I'd like to know about it and learn.
> It'll have to wait two days 'til I get back to work, though... I'll post
> it asap.
Well, so much for asap, but here's what I used (with one correction: in
the 'if' code I had forgotten to actually reference the missing
attribute, so the __getattr__ look up never happened; now the
try...except block is /slightly/ faster, as opposed to 20% slower).
def __call__(self, x, y, z):
mongo = self.mongo
mongo = self.mongo = 1
def __getattr__(self, name):
if name != 'mongo':
self.mongo = 1
def __call__(self, x, y, z):
self.mongo # didn't have this line before. d'oh!
--> timeit.Timer('spammer(1,2,3)','from spam import spam_except;
--> timeit.Timer('spammer(1,2,3)','from spam import spam_if;