[Python-3000] hash as attribute/property

[Guido van Rossum]

On 4/4/06, Giovanni Bajo <rasky at develer.com> wrote:
> Guido van Rossum <guido at python.org> 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/)