Guido van Rossum wrote:
>> __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
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 ea
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 obje
Delaney, Timothy (Tim) wrote:
> 2. If it's a property, subclasses need to override the getter and
> recreate the property if they want to change the hash of the object
> (unless the base class uses a lazy property).
In which case the performance advantage becomes
negative (instead of just a metho
Guido van Rossum wrote:
> 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).
Another thought is how frequently the method/attribute
is going to be used. I can't even remember when was
Barry Warsaw wrote:
> While we were at it, we changed everything
> that returns a newly formed concrete sequence to returning an iterator
> (which broke code that was doing random access into the sequence,
That sounds like a good use for Py3k-style views!
--
Greg
_
Barry Warsaw wrote:
> Certainly "foo.get_something()" and
> "foo.set_something(thing)" are much better spelled "foo.something" and
> "foo.something = thing".
If you already have a get/set pair, that definitely
makes sense. If hash() had been spelled get_hash()
it might have made sense there too.
Guido van Rossum wrote:
> We apparently need more guidance for when it's appropriate to turn
> something into an attribute.
I'd suggest that things which could require substantial
computation to obtain should remain methods; hash()
seems to fall into that category.
--
Greg
__
Guido van Rossum wrote:
> 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.
Yeah - I felt it was a borderline case, so thought i
On 4/4/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Just a data point. In our API, we've been converting all of our no-arg
> methods to attributes/properties, each of which may or may not be
> writable of course. It's simplified our Python code enormously, and
> made it much more readable. Cert
On 4/4/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-04-04 at 09:57 -0700, Guido van Rossum wrote:
> > On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > > I've been thinking that `hash` could be an attribute (or property if it
> > > needs to be calculated on-the-fly) rat
On Tue, 2006-04-04 at 09:57 -0700, Guido van Rossum wrote:
> On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > I've been thinking that `hash` could be an attribute (or property if it
> > needs to be calculated on-the-fly) rather than the current method call.
> >
> > Or it could be an
On 4/3/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> I've been thinking that `hash` could be an attribute (or property if it
> needs to be calculated on-the-fly) rather than the current method call.
>
> Or it could be an easy thing to add to the "won't change" PEP ...
The latter, please.
13 matches
Mail list logo
