Steven Bethard wrote:
> On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> 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, "__c
On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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
>
On 7/27/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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
>
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 the case
of _
Steven Bethard wrote:
> One alternative that I didn't see mentioned is to drop
> object.__hash__() and introduce something like collections.iddict()
> and collections.idset() for these purposes.
-1. Too big a change for something we're fairly sure
isn't a real problem in the first place.
--
Greg
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 complexity to handle one special case.
FWIW, I don't believe your "solu
On 7/27/06, Guido van Rossum <[EMAIL PROTECTED]> 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 way classes can explic
On 7/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'd be happy to extend the convention to all such attributes --
> > setting it to None to mean that the subclass doesn't want to provide
> > it. That's clean, can't possibly be interpreted to mean anything else,
> > and
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 way classes can explicitly declare that they aren't callable,
hashable, iterable etc. by s
On 7/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 7/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > If I understand the problem right, the reason for not wanting to
> > remove __hash__ from object is that it's often convenient to have a
> > dict or set where objects are compared by
On 7/27/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> If I understand the problem right, the reason for not wanting to
> remove __hash__ from object is that it's often convenient to have a
> dict or set where objects are compared by id() instead of by value.
No, not at all. This is for objects
[Guido van Rossum]
> I propose to take the same approach as for callable: if it has
> __hash__ we consider it hashable even though the hash may fail
[Greg Ewing]
> Fair enough, although since object has __hash__
> we end up concluding that everything is
> hashable except when it isn't. :-)
[Guido
> While this makes sense from the perspective you mention, paraphrased
> as "different objects have different capabilities, and I want to query
> what capabilities this object has," I'm not convinced that any but the
> most uncommon uses involve enumerating the capabilities of an object.
> And thos
On 7/26/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> * Uniform -- the general form of the inquiry does not
> depend on the particular capability being inquired about
While this makes sense from the perspective you mention, paraphrased
as "different objects have different
Guido van Rossum wrote:
> On 7/26/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>class Unhashable(object):
>>__hash__ = Undefined
>
> Simpler: set it to None. That could be a convention.
>
And someone else pointed out that this could still be a trigger for NULL'ing
out slots at the C
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> I'd be happy to extend the convention to all such attributes --
>> setting it to None to mean that the subclass doesn't want to provide
>> it. That's clean, can't possibly be interpreted to mean anything else,
>> and doesn't require you to actually
16 matches
Mail list logo
