On 4/4/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > The question is where to draw the line. I don't believe you really > > meant "all no-args methods". Perhaps you meant "all side-effect free > > argument-less methods that return the same value each time (or at > > least until some explicit change to the object is made) and that can > > be computed reasonably cheap"? > > +1. And "reasonably cheap" also means O(1) (aka "no for loops"), in my own > rule > of thumb. The worst thing of VB is when you read a value from a property and > don't realize how much it's going on behind the scenes. > > A function call is a function call is a function call. Someone smart said "one > thing is to read code which calls functions that you don't know about, another > thing is to read code where you do not even know where the function calls > are". > This is very true, and should be kept in mind when designing code with > properties. > > > The __hash__() method qualifies, which is why it's a tough call (I'll > > come back on that; I want to come up with a reason why __hash__() > > should remain a method). The iterator-getting example above doesn't > > qualify. > > __hash__() isn't always O(1), so in my world it wouldn't be a property.
I like this best of all the arguments presented so far, and consider the case closed. (The weakness of the argument "but hash() can take a long time to compute" is that a good hash function is supposed to be fast. But this doesn't mean it can't have an O(N) component somewhere, e.g. for tuples.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
