> > I felt uncomfortable about exposing the implementation that way
> ...but double-underscore methods are part of the language definition,
> not part of the implementation.
Yes and no. For example, it appears to be part of the language definition
that foo() is equivalent to foo.__call__(), but apparently not every object
that has a __hash__ attribute is hashable.
> > since object has __hash__ we end up concluding that everything is
> > hashable
> Fortunately, I (and apparently others) believe this limitation is
> OK because there is no need to test for hashability without evoking
> the side effects. In general, __hash__ should be "quick" (which may
> be a relative term) and return the same value each time it is
> called, so simply calling __hash__ to find whether it works ought
> to do nicely.
Indeed -- but I think this statement is still pulling us away from my
original observation, which I might state this way:
Some objects support particular capabilities. That is, you can do
particular things with those objects and not others. I think it would be
useful if there were a way to find out whether an object has a given
capability that is
* Uniform -- the general form of the inquiry does not
depend on the particular capability being inquired about
* Free of side effects
My general experience has been that such inquiries should not be coupling
too closely to the details of the language definition, because such coupling
makes it more difficult to maintain uniformity over time.
One of my concerns about hasattr(foo, '__call__') is that it is not uniform:
You can't test hashability by calling hasattr(foo, '__hash__'). Another is
that it is too closely coupled. For example, if foo.__call__ exists but is
None, is foo callable?
Apparently this is an issue that doesn't concern most of the people on this
list, in which case I'll just chalk it up to different people having
different backgrounds. Nevertheless, I feel that removing callable() from
Python-3000 is a step backward.
_______________________________________________
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
