Re: [Python-3000] callable()
> But you've just pointed out that they're *not* > the same kind of concept, no matter how much > you might wish that there were. > The only way to make hashability testable at > less cost than attempting to do it would be > to have a separate __is_hashable__ method for > that purpose, which would recursively test > contents when necessary. This issue started out as a question of side effects; from an architectural viewpoint, I consider performance to be less important because side effects are likely to affect correctness. So I don't particularly care whether testing for hashability is less expensive than trying to do the hash. What I do care about is being able to determine whether an object has a particular property without having to worry about whether I might change the state of the system in whatever ways are necessary to compute that property. This question is probably sharpest for callability, because it is clear that evaluating foo() might do anything at all, and sometimes I want to control when that anything happens. Nevertheless, I don't agree that testing hashability has to be as expensive as computing the hash. As a simple example, one can see instantly that even a very long string is hashable, even though computing the value of the hash might take a long time if the string is large. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
On 7/23/06, Andrew Koenig <[EMAIL PROTECTED]> wrote: > > But you've just pointed out that they're *not* > > the same kind of concept, no matter how much > > you might wish that there were. > > > The only way to make hashability testable at > > less cost than attempting to do it would be > > to have a separate __is_hashable__ method for > > that purpose, which would recursively test > > contents when necessary. > > This issue started out as a question of side effects; from an architectural > viewpoint, I consider performance to be less important because side effects > are likely to affect correctness. > > So I don't particularly care whether testing for hashability is less > expensive than trying to do the hash. What I do care about is being able to > determine whether an object has a particular property without having to > worry about whether I might change the state of the system in whatever ways > are necessary to compute that property. > > This question is probably sharpest for callability, because it is clear that > evaluating foo() might do anything at all, and sometimes I want to control > when that anything happens. > > Nevertheless, I don't agree that testing hashability has to be as expensive > as computing the hash. As a simple example, one can see instantly that even > a very long string is hashable, even though computing the value of the hash > might take a long time if the string is large. I propose to take the same approach as for callable: if it has __hash__ we consider it hashable even though the hash may fail (e.g. if it's a tuple containing an unhashable object). This is roughly equivalent to the usefulness of callable: the call may still fail if the signature doesn't match. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] callable()
Guido van Rossum wrote: > I propose to take the same approach as for callable: if it has > __hash__ we consider it hashable even though the hash may fail Fair enough, although since object has __hash__ we end up concluding that everything is hashable except when it isn't. :-) -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
