Steven Bethard wrote:
> I thought about this for a while, and I think maybe a good rule of
> thumb (and something like what Python seems to follow) is: "If it's
> there's an obvious default implementation of a protocol that would be
> generally useful, it should go on all objects."
Please, no!
O
"Stian Soiland" <[EMAIL PROTECTED]> wrote:
>
> On 7/11/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> > >>> d={1:'one', 1.0:'one'}
> > >>> d
> > {1: 'one'}
>
> This highlights the problem. Imagine that you don't type out the
> actual objects, but just receive them:
>
> def make_dict(x, y, obj)
On 7/11/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> >>> d={1:'one', 1.0:'one'}
> >>> d
> {1: 'one'}
This highlights the problem. Imagine that you don't type out the
actual objects, but just receive them:
def make_dict(x, y, obj):
return {x: obj, y: obj}
x1 = x2 = "fish"
d = make_dict(x1, x
On 7/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > [1] It might get you something for __hash__() if object.__hash__() is
> > not removed, but that debate still seems to be in progress and I'm not
> > sure it's worth the added complexi
On 7/28/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> Methinks that the suggestion includes defining hashable(x) in such a way as
> to give the right answer, irrespective of how x.__hash__ is defined.
I'm getting tired of this discussion, so I'm just going to stop
reading this thread.
--
--Guid
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Use cases for a "may be hashable" pretest are much weaker (and typically
> hypothetical), but there are cases where it makes a certain amount of sense.
> For example, if you have a set-based fast path if all the objects being
> handled are hashable, and
Steven Bethard wrote:
> If object.__hash__() disappeared, the hash(obj) versions would fail,
> but the same results seem to be available as hash(id(obj)).
Not in Jython - Jython's id() is expensive so the default hash() doesn't use it.
Last time the idea of getting rid of object.__hash__() came u
Andrew Koenig wrote:
> I note in PEP 3000 the proposal to remove callable(), with the comment "just
> call the object and catch the exception."
>
> I think that's a bad idea, because it takes away the ability to separate the
> callability test from the first call. As a simple example, suppose you
Marcin 'Qrczak' Kowalczyk wrote:
> Stefan Behnel <[EMAIL PROTECTED]> writes:
>
>> So, if hashable() returns True, it means that a) the designer didn't
>> care about switching it off or b) there are cases where it works, so
>> it makes sense to try calling it.
>
> If the code can successfully work
> Guido van Rossum wrote:
> > So how about we change callable() and add hashable(), iterable() and
> > whatever else makes sense so that these all become like this:
> >
> > def callable(x):
> > return getattr(x, "__call__", None) is not None
> This *still* doesn't fully solve the problem in
Stefan Behnel <[EMAIL PROTECTED]> writes:
> So, if hashable() returns True, it means that a) the designer didn't
> care about switching it off or b) there are cases where it works, so
> it makes sense to try calling it.
If the code can successfully work with either hashable or non-hashable
object
Marcin 'Qrczak' Kowalczyk wrote:
> Stefan Behnel <[EMAIL PROTECTED]> writes:
>
>> It just says: I support the protocol, so it makes sense to apply the
>> protocol operations to me if you need to.
>>
>> I think that's perfectly reasonable semantics for the three functions.
>
> I see no essential
Stefan Behnel <[EMAIL PROTECTED]> writes:
> It just says: I support the protocol, so it makes sense to apply the
> protocol operations to me if you need to.
>
> I think that's perfectly reasonable semantics for the three functions.
I see no essential difference between an object which doesn't sup
13 matches
Mail list logo
