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 call the attribute.
Altho
> > 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
Andrew Koenig writes:
> I started the thread because I wanted to call attention to an issue: Objects
> sometimes have properties that have side effects when exploited, and it can
> be useful to be able to test for the presence of such properties without
> evoking the side effects.
Good point. I ag
On 7/25/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Ivan Krstic wrote:
> > Python already has
> > just enough programmable bits in place to invite abuse which emulates
> > programmable syntax; look at SQLObject or SQLalchemy for examples.
>
> Also, the "just use a string" workaround means that
> pe
On 7/26/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> In other words, the current notion appears to be:
>
> An object is callable iff it has a __call__ attribute.
>
> An object is hashable iff its __hash__ attribute is not None.
>
> This example only strengthens my original intuiti
> > I for one have gotten along quite happily without
> > ever wanting to test for hashability.
> Me too, as said elsewhere. This whole thread seems like a purely
> theoretical debate.
That may be because it has departed from its original intent.
I started the thread because I wanted to call att
On Wednesday 2006-07-26 07:20, Greg Ewing wrote:
> Andrew Koenig wrote:
> > I think of a
> > function f as being idempotent if f(x) == x for all x in dom(f).
>
> Um, that's an identity function, isn't it? I think
> you mean something more like f(f(x)) == f(x).
>
> But even that's not quite what w
On 7/26/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>class Unhashable(object):
>__hash__ = Undefined
Simpler: set it to None. That could be a convention.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 maili
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> Personally, I'm not sure this problem needs solving; I don't recall
>> ever needing to know whether something is hashable.
>
> I for one have gotten along quite happily without
> ever wanting to test for hashability.
Me too, as said elsewhere. This
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> The use case is being able to block the inheritance of special methods
>> that object provides default implementations for (like '__hash__'),
>> such that a hasattr() check (or a check for a type slot being 0) for
>> those special methods will actual
Nick Coghlan wrote:
> The use case is being able to block the inheritance of special methods
> that object provides default implementations for (like '__hash__'), such
> that a hasattr() check (or a check for a type slot being 0) for those
> special methods will actually fail.
Maybe descriptor
Guido van Rossum wrote:
> Ouch, that's a problem indeed. There's not really a clean way out
> unfortunately: either we remove object.__hash__ and let hash() do the
> default implementation, and then presence of __hash__ is no longer an
> indicator of hashability; or we keep it, and override it to r
Guido van Rossum wrote:
> Personally, I'm not sure this problem needs solving; I don't recall
> ever needing to know whether something is hashable.
I for one have gotten along quite happily without
ever wanting to test for hashability.
--
Greg
___
Pyth
13 matches
Mail list logo
