On Dec 3, 2010, at 7:05 PM, Terry Reedy wrote: > I left out that the id must be an int. > >> It's somewhat unfortuante that python has this constraint, instead of >> the looser: "objects have a fixed id during their lifetime", which is >> much easier to implement, and practically as useful. > > Given that the only different between 'fixed and unique' and 'fixed' is the > uniqueness part, I do not understand 'practically as useful'. Duplicate ids > (in the extreme, that same for all objects) hardly seem useful at all.
Sure they are. This is what Java provides you, for example. If you have fixed, but potentially non-unique ids (in Java you get this using "identityHashCode()"), you can still make an identity hashtable. You simply need to *also* check using "is" that the two objects really are the same one after finding the hash bin using id. It'd be a quality of implementation issue whether an implementation gives you the same value for every object. It should not, of course, if it wants programs to have reasonable performance. Same sort of thing as how __hash__ should not return 0 for everything. Besides identity-hashtables, the main other thing id gets used for is to have some identifier string in a printer (e.g. "<class Foo at 0x1234567890>"). There, it's generally "good enough" to use an id which is not guaranteed to be, but often is, unique. It works for Java... James _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
