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
people are effectively doing this anyway, but in an
uglier and le
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 we're talking about
here, because we're not hashing the result of
Collin Winter wrote:
> On 7/25/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
>>> With your CD example, you need an external resource (the CD itself) in
>>> order to calculate the hash - in that case, you can't safely defer
>>> the hash calculation until the first time you know you need it,
>>> sinc
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 raise an
exception in unhashable
On 7/25/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > With your CD example, you need an external resource (the CD itself) in
> > order to calculate the hash - in that case, you can't safely defer
> > the hash calculation until the first time you know you need it,
> > since you don't know whether
Andrew Koenig wrote:
> It's still the case that evaluating a hash might be expensive the
> first time you do it, so you may want to be able to test whether it
> can be done and actually do it only later.
I think you're doing a lot of guess-work here. In real world situations,
computing the hash i
> With your CD example, you need an external resource (the CD itself) in
> order to calculate the hash - in that case, you can't safely defer
> the hash calculation until the first time you know you need it,
> since you don't know whether or not you'll have access to the
> physical CD at that point
Guido van Rossum wrote:
> I'd like to see this fall under the blanket "Python will not have
> programmable syntax" rule in PEO 3099.
Why?
I understand your general position, but categorically rejecting anything
smelling of metasyntax seems ill-conceived to me. Python already has
just enough progr
Andrew Koenig wrote:
>> All of which is a long-winded way of saying "calculation of an object hash
>> should be both cheap and idempotent" :)
>
> Actually, I disagree -- I don't see why there's anything wrong with a hash
> being expensive to calculate the first time you do it.
True, but if you ca
> All of which is a long-winded way of saying "calculation of an object hash
> should be both cheap and idempotent" :)
Actually, I disagree -- I don't see why there's anything wrong with a hash
being expensive to calculate the first time you do it.
For example, consider a string type in which the
Andrew Koenig wrote:
>> In both cases, __hash__ is not idempotent, and is thus an abomination.
>
> Why do you say it's not idempotent? The first time you call it, either it
> works or it doesn't. If it doesn't work, then you shouldn't have called it
> in the first place. If it does work, all su
11 matches
Mail list logo
