On 2004-12-29, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> Op 2004-12-23, Scott David Daniels schreef <[EMAIL PROTECTED]>:
>>>This is half the problem. In the period where an element is in the
>>>wrong hash bucket, a new entry for the same value can be created in
>>>th
On Thu, 30 Dec 2004 17:36:57 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> Essentially syntactic sugar to avoid writing id(obj) ? (and to get a little
>> performance
>> improvement if they're written in C). I can't believe this thread came from
>> the
>> lack of such su
Bengt Richter wrote:
Essentially syntactic sugar to avoid writing id(obj) ? (and to get a little
performance
improvement if they're written in C). I can't believe this thread came from the
lack of such sugar ;-)
The downside of doing it that way is you have no means of getting from the id()
store
On Wed, 29 Dec 2004 22:47:55 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>said>
>
>Bengt Richter wrote:
>> A second time a key may be hashed is when it is used as a lookup key. This
>> can be a reference to
>> the identical key object first used, or it can be a new object. A new object
>> has
Antoon Pardon wrote:
Op 2004-12-23, Scott David Daniels schreef <[EMAIL PROTECTED]>:
This is half the problem. In the period where an element is in the
wrong hash bucket, a new entry for the same value can be created in
the proper hash bucket. Then the code will have to determine how to
merge two
Bengt Richter wrote:
A second time a key may be hashed is when it is used as a lookup key. This can
be a reference to
the identical key object first used, or it can be a new object. A new object
has to be hashed in order
to have a hash value to use in finding candidate keys to compare to. If _th
On Sun, 26 Dec 2004 12:17:42 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> I take it you are referring to regular python dictionaries,
>
>Correct. So I'll skip over the sections talking about alternate lookup
>strategies in my reply.
Cool.
>
>>>Anyway, what are the conse
Bengt Richter wrote:
I take it you are referring to regular python dictionaries,
Correct. So I'll skip over the sections talking about alternate lookup
strategies in my reply.
Anyway, what are the consequences of a type which has a 'variable hash'?
The only real bad consequence is that the intern
On Wed, 22 Dec 2004 22:57:01 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>OK, I think I need to recap a bit before starting my reply (for my own
>benefit,
>even if nobody else's). (The rest of this post will also include a fair bit of
>repeating things that have already been said elsewhere i
Antoon Pardon wrote:
Op 2004-12-22, Jeff Shannon schreef <[EMAIL PROTECTED]>:
The problem is that once the object has mutated, you *don't know* what
bucket it used to sort into. There is no point at which a dictionary
can see "before" and "after" -- it just sees two different lists.
This is half
Op 2004-12-23, Scott David Daniels schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2004-12-22, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>>The problem is that once the object has mutated, you *don't know* what
>>>bucket it used to sort into. There is no point at which a dictionary
>>>
Antoon Pardon wrote:
I don't understand why the ease of mutating an object that should remain
stable should cause more unease in a person just because the subject
is dictionary keys, except maybe because of custom.
But I'm obviously in the minority here.
Nah - just fighting against long-held assump
Antoon Pardon wrote:
I don't think I would recommend adding hash methods to mutable builtins.
Storing keys by identity or value both can make sense for these kind
of objects. And since python prefers not to guess I think it is a good thing
there is no default hash for mutable objects.
In that case,
Op 2004-12-23, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Steven Bethard wrote:
>> Of course, if rehash worked in place, you could probably do some
>> optimizations to only rehash the necessary items.
>
> Yep, especially given this little critter from dictobject.h which contains
> everything nee
Jeff Shannon <[EMAIL PROTECTED]> wrote:
...
> But, you generally don't "retrieve" _keys_ from dicts. You *use* keys
> to retrieve *values* from a dict. The only way to get a dict to give
> you a key is by using the keys() method (or items() method) to give you
> *all* of the keys.
There are
Op 2004-12-22, Nick Coghlan schreef <[EMAIL PROTECTED]>:
>> I'm currently not under the impression I'm able to. Sure I could
>> implement the above mentioned classes, but my feeling is that
>> should I present them here, nobody would be waiting for them.
>> Not because they would be unusfull, but b
Op 2004-12-22, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>>Antoon Pardon wrote:
>>>
>>>
>>>So show us a dictionary (i.e. hash table) implementation that can do
>>>this.
>>>
>>>
>>
>>Why should I, D
Op 2004-12-22, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>How does the dict know which value is associated with which key?
>>
>>
>>
>>Because there is a link between the key and the value. The problem
>>
Steven Bethard wrote:
Of course, if rehash worked in place, you could probably do some
optimizations to only rehash the necessary items.
Yep, especially given this little critter from dictobject.h which contains
everything needed to spot mutated objects:
typedef struct {
long me_hash;
Jeff Shannon wrote:
To be honest, given how easy it is to key a current dict off of object
id, I don't see much real value in creating a separate dict type that
does it by default. But as long as it's an addition, rather than a
change to existing behavior, then the only real problem with it is
Jeff Shannon <[EMAIL PROTECTED]> wrote:
...
> hashes) is that, for a well-behaved hash function, then A == B should
> imply that hash(A) == hash(B). (The reverse is *not* true, however --
> hash(A) == hash(B) does not necessarily say anything about whether A == B.)
>
> If that is a correct con
Nick Coghlan wrote:
I have a different suggestion: an identity dictionary.
It ignores __hash__, __cmp__ and __eq__, and instead uses id() and is.
This might be useful in some special cases, though it's pretty easy to
use a standard dict and explicitly use object ids as keys ( d[id(myobj)]
= ...
Nick Coghlan wrote:
The longer I consider it, the more this seems like a valid analogy.
There is nothing preventing dictionaries from having a rehash() method.
Consider:
# Mutate some value in mylist
mylist.sort()
# Mutate some key in mydict
mydict.rehash()
Well, you can already get the equivalen
Antoon Pardon wrote:
Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
How does the dict know which value is associated with which key?
Because there is a link between the key and the value. The problem
with a mutated key in a dictionary is not that the link between the
key and the va
Antoon Pardon wrote:
Well the only suggestion I would make now is that it would be nice to
have a second dict type that would make a copy of a key and insert
that copy in the dictionary.
(At least) two options here, depending on what you really need.
(1) Use current dicts. They will still give you
Antoon Pardon wrote:
Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
Antoon Pardon wrote:
So show us a dictionary (i.e. hash table) implementation that can do
this.
Why should I, Do you doubt that it is possible?
Yes.
You'll need to be able to derive the old hash from the
OK, I think I need to recap a bit before starting my reply (for my own benefit,
even if nobody else's). (The rest of this post will also include a fair bit of
repeating things that have already been said elsewhere in the thread)
The actual rule dictionaries use when deciding whether or not
Op 2004-12-22, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> But this was another subthread.
>
> oh, sorry, I was under the flawed assumption that the first few posts to a
> thread should be seen in the context of the original post.
So? In the mean time there have been mor
Op 2004-12-22, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 21 Dec 2004 10:37:20 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2004-12-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
As it turns out, python makes no difference in difficulty for making
either mutable or immutab
Antoon Pardon wrote:
> But this was another subthread.
oh, sorry, I was under the flawed assumption that the first few posts to a
thread should be seen in the context of the original post. I guess I'm a bit
too old-fashioned for these new-fangled "let's change the subject for each
new post witho
Op 2004-12-22, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>> and to temporarily refer back to the top of this thread, do all this without
>>> any performance impact, compared to the current implementation.
>>>
>> Why should that be? This originated when someone argued that
On 21 Dec 2004 10:37:20 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>Op 2004-12-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
>>>
>>>As it turns out, python makes no difference in difficulty for making
>>>either mutable or immutable objects usable as dictionary keys. The
>>>only difference is t
Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>>Now, even if hash were made to equal id... suppose I then pass that dict
>>>to a function, and I want to get the value that I've stored under
>>>
Antoon Pardon wrote:
>> and to temporarily refer back to the top of this thread, do all this without
>> any performance impact, compared to the current implementation.
>>
> Why should that be? This originated when someone argued that lists could
> easily be resorted and reheapified.
from the orig
Op 2004-12-21, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Jeff Shannon wrote:
>
>> So show us a dictionary (i.e. hash table) implementation that can do this.
>> You'll need to be able
>> to derive the old hash from the new hash, of course, so that you can
>> correctly associate the
>> values
Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-21, Nick Coghlan schreef <[EMAIL PROTECTED]>:
>>
>>
>>>Antoon Pardon wrote:
>>>
>>>
Why then doesn't python think the same about sorted lists. When I have a
sorted list and do operations on
Antoon Pardon wrote:
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
Now, even if hash were made to equal id... suppose I then pass that dict
to a function, and I want to get the value that I've stored under
[1,2]. In order to do that, I'd *also* have to pass in the *exact* list
tha
Jeff Shannon wrote:
> So show us a dictionary (i.e. hash table) implementation that can do this.
> You'll need to be able
> to derive the old hash from the new hash, of course, so that you can
> correctly associate the
> values already stored under that key. And you'll have to be able to do
Antoon Pardon wrote:
Op 2004-12-21, Nick Coghlan schreef <[EMAIL PROTECTED]>:
Antoon Pardon wrote:
Why then doesn't python think the same about sorted lists. When I have a
sorted list and do operations on it that depend on it being sorted,
I can mess things up just as easily by mutating an
Op 2004-12-21, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Why then doesn't python think the same about sorted lists. When I have a
>> sorted list and do operations on it that depend on it being sorted,
>> I can mess things up just as easily by mutating an element in that
>>
Antoon Pardon wrote:
Why then doesn't python think the same about sorted lists. When I have a
sorted list and do operations on it that depend on it being sorted,
I can mess things up just as easily by mutating an element in that
sorted list as I can mess things up by mutating a dictionary key.
Inco
Op 2004-12-18, Roy Smith schreef <[EMAIL PROTECTED]>:
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [quoting from the Reference Manual]
>> If a class defines mutable objects and implements a __cmp__()
>> or __eq__() method, it should not implement __hash__(), since the dictionary
>> implementation
Op 2004-12-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
>>
>>As it turns out, python makes no difference in difficulty for making
>>either mutable or immutable objects usable as dictionary keys. The
>>only difference is that python only made its standard immutable
>>types hashable and not its sta
Op 2004-12-18, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Jp Calderone wrote:
>> On Fri, 17 Dec 2004 11:21:25 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote:
>>
>> The correct characterization is that Python makes user-defined
>> mutable classes hashable (arguably correctly so) as the default
>>
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>>To take another approach -- given some function that allows lists to
>>>(pretend to be) hashable:
>>>
>>>.>>> key = [1,2]
>>>.>>> d[key] = 'foo'
>
Op 2004-12-18, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Would you have us construct two related classes each time we find
>> ourselves in such a situation and copy an object from one
>> class to the other depending on the circumstances?
>
> Python itself seems to think so
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>
>>>(And I have to reiterate, here, that I have *never* felt it a hardship
>>>to be unable to use lists as dictionary keys; it's just never come up
On 2004-12-17, John Roth <[EMAIL PROTECTED]> wrote:
> I came in on this thread a bit late. The strictly
> pragmatic answer to the question in the
> header should be obvious.
>
> If tuples were mutable, then there would be
> no difference between tuples and lists, so
> there would be no need for tup
Nick Coghlan <[EMAIL PROTECTED]> wrote:
[quoting from the Reference Manual]
> If a class defines mutable objects and implements a __cmp__()
> or __eq__() method, it should not implement __hash__(), since the dictionary
> implementation requires that a key's hash value is immutable (if the object'
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Although, it looks like new-style classes currently don't apply this
> rule - you get the default hash implementation from object no matter
> what:
>
> Py> class NotHashable(object):
> ... def __cmp__(self, other):
Nick Coghlan wrote:
Although, it looks like new-style classes currently don't apply this
rule - you get the default hash implementation from object no matter what:
That may be a bug rather than a feature :)
And indeed it is:
http://sourceforge.net/tracker/index.php?func=detail&aid=660098&group_id
Jeff Shannon wrote:
That does put a kink in my argument that Python is simply refusing to
guess in the face of ambiguity. I'm still convinced that disallowing
lists as dict keys is a good thing, but it leaves me unable to explain
why __hash__()-less user-defined classes (which are mutable almos
Jp Calderone wrote:
On Fri, 17 Dec 2004 11:21:25 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote:
The correct characterization is that Python makes user-defined
mutable classes hashable (arguably correctly so) as the default
behavior.
However, that is only achieved by using identity based equality
Antoon Pardon wrote:
Would you have us construct two related classes each time we find
ourselves in such a situation and copy an object from one
class to the other depending on the circumstances?
Python itself seems to think so, given the pairings of set/frozenset &
list/tuple.
Using genuinely imm
In article <[EMAIL PROTECTED]>,
Jeff Shannon <[EMAIL PROTECTED]> wrote:
> Roy Smith wrote:
> >All that's needed is to define __hash__() and __cmp__() methods which
> >only look at some subset of the object's data atrributes. You can
> >keep those attributes constant (perhaps enforced with __seta
On 17 Dec 2004 08:20:10 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>> Adam DePrince wrote:
>>
>>>And how exactly do you propose to mutate an object without changing its
>>>hash value?
>>>
>>>
>>>* Create this mutate-able object type.
>
Jp Calderone wrote:
On Fri, 17 Dec 2004 11:21:25 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote:
No -- the mathematical definition of 'hashable' fails for mutable types,
and Python doesn't try to pretend that it can hash mutable types.
Python also provides features so that user-defined immutab
Roy Smith wrote:
Jeff Shannon <[EMAIL PROTECTED]> wrote:
The aesthetic purity I'm referring to is that Python respects the proper
meaning of hashing, even if it doesn't force the programmer to. The
builtin objects that Python provides don't offer a __hash__() method
that fails to meet the m
I came in on this thread a bit late. The strictly
pragmatic answer to the question in the
header should be obvious.
If tuples were mutable, then there would be
no difference between tuples and lists, so
there would be no need for tuples.
Whether you think an immutable list is
worth while is a diffe
Jeff Shannon <[EMAIL PROTECTED]> wrote:
> The aesthetic purity I'm referring to is that Python respects the proper
> meaning of hashing, even if it doesn't force the programmer to. The
> builtin objects that Python provides don't offer a __hash__() method
> that fails to meet the mathematical
On Fri, 17 Dec 2004 11:21:25 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote:
>
> No -- the mathematical definition of 'hashable' fails for mutable types,
> and Python doesn't try to pretend that it can hash mutable types.
> Python also provides features so that user-defined immutable types can
Antoon Pardon wrote:
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
To take another approach -- given some function that allows lists to
(pretend to be) hashable:
.>>> key = [1,2]
.>>> d[key] = 'foo'
.>>> d[[1,2]]
.>>> key.append(3)
.>>> d[key]
???
.>>>
As I understand it, it is
Antoon Pardon wrote:
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
(And I have to reiterate, here, that I have *never* felt it a hardship
to be unable to use lists as dictionary keys; it's just never come up
that the data that I had in a list was something that I wanted to use
as-
jfj wrote:
Why can't we __setitem__ for tuples?
It seems from your suggestions here that what you really want is a
single sequence type, list, instead of two sequence types: tuple and
list. Under your design, list would support hash, and it would be up to
the programmer to make sure not to modi
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>
>>>nevermind the fact that I can't think of a case where I'm
>>>likely to "retrieve" a key from a dict, modify it, and then put it
>>>back. (I c
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Adam DePrince wrote:
>
>>And how exactly do you propose to mutate an object without changing its
>>hash value?
>>
>>
>>* Create this mutate-able object type.
>>* Create two objects that are different with different hash values.
>>* Mutate
Antoon Pardon wrote:
Op 2004-12-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
nevermind the fact that I can't think of a case where I'm
likely to "retrieve" a key from a dict, modify it, and then put it
back. (I can think of endless cases where I'd want to do that with
*values*, but not wit
Adam DePrince wrote:
And how exactly do you propose to mutate an object without changing its
hash value?
* Create this mutate-able object type.
* Create two objects that are different with different hash values.
* Mutate one so that it is the same as the other.
* Compare their hash values.
If
>Roy Smith wrote:
>> def __cmp__ (self, other):
>> # I wish there was a less verbose way to do this!
>> if self.block < other.block:
>> return -1
>> if self.block > other.block:
>> return 1
>> if self.lot < other.lot:
>> return -1
Roy Smith wrote:
class Property:
def __init__ (self, block, lot, zoning="Unknown"):
self.block = block
self.lot = lot
self.zoning = zoning
def __hash__ (self):
return (self.block + self.lot)
def __cmp__ (self, other):
# I wish there was a less ver
Fredrik Lundh wrote:
how does the dictionary know if you want key value equality or key
identity equality?
By the __hash__ and __eq__ methods you provide on your object.
so what you're saying is that Python dictionaries should work just like
Python dictionaries work today.
sorry for wasting my time
Max M <[EMAIL PROTECTED]> wrote:
> The problem is that you don't understand what dicts are typically used
> for. Because of the nonliniarity in dict lookups, dicts are used for
> optimisation.
To me, dicts are first and foremost used when you want a mapping
relationship where the key is not a v
> def __cmp__ (self, other):
> # I wish there was a less verbose way to do this!
> if self.block < other.block:
> return -1
> if self.block > other.block:
> return 1
> if self.lot < other.lot:
> return -1
> if self.lot >
Adam DePrince <[EMAIL PROTECTED]> wrote:
> And how exactly do you propose to mutate an object without
> changing its hash value?
That's easy. Define a hash function that doesn't use all the data in
the object.
class Foo:
def __init__ (self, a, b, c):
self.a = a
self.b
Op 2004-12-16, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>> how does the dictionary know if you want key value equality or key
>>> identity equality?
>>
>> By the __hash__ and __eq__ methods you provide on your object.
>
> so what you're saying is that Python dictionaries
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Antoon Pardon wrote:
>
>> That depends on whether the programmes wants value equality
>> or identity equality.
>
> how does the dictionary know if you want key value equality or key
> identity equality?
Smalltalk has separate Dictionary and IdentityDi
Antoon Pardon wrote:
>> how does the dictionary know if you want key value equality or key
>> identity equality?
>
> By the __hash__ and __eq__ methods you provide on your object.
so what you're saying is that Python dictionaries should work just like
Python dictionaries work today.
sorry for wa
Op 2004-12-16, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Two guidelines can make it easier for a programmer to do this.
>>
>> 1) Put a copy in the dictionary, so that mutating the original
>>object won't affect what is in the dictonary.
>
> What's supposed to happen h
Op 2004-12-16, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> That depends on whether the programmes wants value equality
>> or identity equality.
>>
>> In the first case the programmer shouldn't mutate a after
>> it was introduced as key in the dictionary; but should
>> eit
Antoon Pardon wrote:
> That depends on whether the programmes wants value equality
> or identity equality.
>
> In the first case the programmer shouldn't mutate a after
> it was introduced as key in the dictionary; but should
> either introduce a copy or work on a copy later. As
> such your snippe
Op 2004-12-16, Max M schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Well IMO there are two sides in this argument. The first is whether
>> or not python allows mutable keys. The second is whether or not
>> limiting keys to immutables in dictionaries provides a performance
>> gain.
>
>
> T
Antoon Pardon wrote:
Well IMO there are two sides in this argument. The first is whether
or not python allows mutable keys. The second is whether or not
limiting keys to immutables in dictionaries provides a performance
gain.
The problem is that you don't understand what dicts are typically used
Antoon Pardon <[EMAIL PROTECTED]> writes:
> Two guidelines can make it easier for a programmer to do this.
>
> 1) Put a copy in the dictionary, so that mutating the original
>object won't affect what is in the dictonary.
What's supposed to happen here?
a = [1,2,3]
d[a] = 9
a.appe
Op 2004-12-16, Jeremy Bowers schreef <[EMAIL PROTECTED]>:
> On Wed, 15 Dec 2004 15:08:09 +, Antoon Pardon wrote:
>
>> And I think that is a stupid reason. There are enough other situations
>> were people work with mutable objects but don't wish to mutate specific
>> objects. Like objects in a
Op 2004-12-15, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2004-12-15, Roel Schroeven schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
>sorry, but I don't understand your reply at all. a
Op 2004-12-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Demanding that users of dictioanaries somehow turn their mutable objects
>>into tuples when used as a key and back again when you retrieve the keys
>>and need the object [...]
>>
>
> But, you generally don't "retrie
On Thu, 16 Dec 2004 00:56:50 -0500, Jeremy Bowers wrote:
> editing with the object representing the GUI widget; I actually give each
> editable object a guaranteed unique id on creation, never changed, and I
> define __eq__(self, other) as "return self is other".
Before anybody asks why I don't u
On Wed, 15 Dec 2004 15:08:09 +, Antoon Pardon wrote:
> And I think that is a stupid reason. There are enough other situations
> were people work with mutable objects but don't wish to mutate specific
> objects. Like objects in a sorted sequence you want to keep that way
> or objects in a heap
On Wed, 2004-12-15 at 10:26, Jp Calderone wrote:
> On Wed, 15 Dec 2004 14:18:21 GMT, Roel Schroeven <[EMAIL PROTECTED]> wrote:
> >Antoon Pardon wrote:
> > > Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> > >>sorry, but I don't understand your reply at all. are you saying that
> > >>d
On Wed, 15 Dec 2004 23:38:04 -0500, Adam DePrince <[EMAIL PROTECTED]> wrote:
>On Wed, 2004-12-15 at 10:26, Jp Calderone wrote:
> > On Wed, 15 Dec 2004 14:18:21 GMT, Roel Schroeven <[EMAIL PROTECTED]> wrote:
> > >Antoon Pardon wrote:
> > > > Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>
On Mon, 2004-12-13 at 17:23, jfj wrote:
> Yo.
>
> Why can't we __setitem__ for tuples?
> The way I see it is that if we enable __setitem__ for tuples there
> doesn't seem to be any performance penalty if the users don't use it
> (aka, python performance independent of tuple mutability).
>
> On t
On Mon, 2004-12-13 at 17:23, jfj wrote:
Yo.
Why can't we __setitem__ for tuples?
The way I see it is that if we enable __setitem__ for tuples there
doesn't seem to be any performance penalty if the users don't use it
(aka, python performance independent of tuple mutability).
On the other ha
Antoon Pardon wrote:
Demanding that users of dictioanaries somehow turn their mutable objects
into tuples when used as a key and back again when you retrieve the keys
and need the object [...]
But, you generally don't "retrieve" _keys_ from dicts. You *use* keys
to retrieve *values* from a dict.
Jp Calderone <[EMAIL PROTECTED]> wrote:
> Dictionaries support mutable keys just find. What they don't
>support is unhashable keys.
>
> For some objects, this is an important distinction: lists are
>mutable but not hashable.
Of course, you could subclass list to make a mutable, hashable li
Antoon Pardon wrote:
Op 2004-12-15, Roel Schroeven schreef <[EMAIL PROTECTED]>:
Antoon Pardon wrote:
Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
sorry, but I don't understand your reply at all. are you saying that
dictionaries
could support mutable keys (e.g lists) by making a copy
On Wed, 15 Dec 2004 14:18:21 GMT, Roel Schroeven <[EMAIL PROTECTED]> wrote:
>Antoon Pardon wrote:
> > Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> >>sorry, but I don't understand your reply at all. are you saying that
> >>dictionaries
> >>could support mutable keys (e.g lists) by
Op 2004-12-15, Roel Schroeven schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
>>>sorry, but I don't understand your reply at all. are you saying that
>>>dictionaries
>>>could support mutable keys (e.g lists) by making a copy of the
Antoon Pardon wrote:
Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
sorry, but I don't understand your reply at all. are you saying that
dictionaries
could support mutable keys (e.g lists) by making a copy of the key? how would
such a dictionary pick up changes to the original key obj
Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>> how would you implement a dictionary where the keys could change, without
>>> any performance penalty compared to the current implementation?
>>
>> The performace gained by using tuples as keys in dictionaries is
Antoon Pardon wrote:
>> how would you implement a dictionary where the keys could change, without
>> any performance penalty compared to the current implementation?
>
> The performace gained by using tuples as keys in dictionaries is
> entirely illusional.
>
> Sure the fact that you use a tuple wh
1 - 100 of 109 matches
Mail list logo
