Mailman 3 November 2005 - Python-Dev

For Python 3k, drop default/implicit hash, and comparison
by Technical Support of Intercable Co Nov. 8, 2005

Nov. 8, 2005

Why 'identity' objects can't define: def __getKey__(self): return Key(self, id(self)) Then they would act as usually, while value object can define def __getKey__(self): return Key(self, self.i, self.j, self.a[1]) (Key is an abstraction to handle subclassing) Of course, there should be a way to handle comparison off the class ierarhy (i think) Today one can write: >>> class Boo(object): def __init__(self,s=""): self.s=s def __hash__(self): … [View More]

1 0

Should the default equality operator compare values instead of identities?
by Noam Raphael Nov. 8, 2005

Nov. 8, 2005

I think it should. (I copy here messages from the thread about the default hash method.) On 11/2/05, Michael Chermside <mcherm(a)mcherm.com> wrote: > > Why not make the default __eq__ really compare the objects, that is, > > their dicts and their slot-members? > > Short answer: not the desired behavior. Longer answer: there are > three common patterns in object design. There are "value" objects, > which should be considered equal if all fields are equal. There … [View More]are > "identity" objects which are considered equal only when they are > the same object. And then there are (somewhat less common) "value" > objects in which a few fields don't count -- they may be used for > caching a pre-computed result for example. The default __eq__ > behavior has to cater to one of these -- clearly either "value" > objects or "identity" objects. Guido chose to cater to "identity" > objects believing that they are actually more common in most > situations. A beneficial side-effect is that the default behavior > of __eq__ is QUITE simple to explain, and if the implementation is > easy to explain then it may be a good idea. > This is a very nice observation. I wish to explain why I think that the default __eq__ should compare values, not identities. 1. If you want to compare identities, you can always use "is". There is currently no easy way to compare your user-defined classes by value, in case they happen to be "value objects", in Michael's terminology - you have to compare every single member. (Comparing the __dict__ attributes is ugly, and will not always work). If the default were to compare the objects by value, and they happen to be "identity objects", you can always do: def __eq__(self, other): return self is other 2. I believe that counter to what Michael said, "value objects" are more common than "identity objects", at least when talking about user-defined classes, and especially when talking about simple user-defined classes, where the defaults are most important, since the writer wouldn't care to define all the appropriate protocols. (this was a long sentence) Can you give examples of common "identity objects"? I believe that they are usually dealing with some input/output, that is, with things that interact with the environment (files, for example). I believe almost all "algorithmic" classes are "value objects". And I think that usually, comparison based on value will give the correct result for "identity objects" too, since if they do I/O, they will usually hold a reference to an I/O object, like file, which is an "identity object" by itself. This means that the comparison will compare those objects, and return false, since the I/O objects they hold are not the same one. 3. I think that value-based comparison is also quite easy to explain: user-defined classes combine functions with a data structure. In Python, the "data structure" is simply member names which reference other objects. The default, value-based, comparison, checks if two objects have the same member names, and that they are referencing equal (by value) objects, and if so, returns True. I think that explaining this is not harder than explaining the current dict comparison. Now, for Josiah's reply: On 11/2/05, Josiah Carlson <jcarlson(a)uci.edu> wrote: > > This leads me to another question: why should the default __eq__ > > method be the same as "is"? If someone wants to check if two objects > > are the same object, that's what the "is" operator is for. Why not > > make the default __eq__ really compare the objects, that is, their > > dicts and their slot-members? > > Using 'is' makes sense when the default hash is id (and actually in > certain other cases as well). Actually comparing the contents of an > object is certainly not desireable with the default hash, and probably > not desireable in the general case because equality doesn't always > depend on /all/ attributes of extension objects. > > Explicit is better than implicit. > In the face of ambiguity, refuse the temptation to guess. > I hope that the default hash would stop being id, as Josiah showed that Guido decided, so let's don't discuss it. Now, about the good point that sometimes the state doesn't depend on all the attributes. Right. But the current default doesn't compare them well too - you have no escape from writing an equality operator by yourself. And I think this is not the common case. I think that the meaning of "in the face of ambiguity, refuse the temptation to guess" is that you should not write code that changes its behaviour according to what the user will do, based on your guess as to what he meant. This is not the case - the value-based comparison is strictly defined. It may just not be what the user would want - and in most cases, I think it will. "Explicit is better than implicit" says only "better". identity-based comparison is just as implicit as value-based comparison. (I want to add that there is a simple way to support value-based comparison when some members don't count, by writing a metaclass that will check if your class has a member like __non_state_members__ = ["_calculated_hash", "debug_member"] and if so, would not compare them in the default equality-testing method. I would say that this can even be made the behavior of the default type.) > I believe the current behavior of __eq__ is more desireable than > comparing contents, as this may result in undesireable behavior > (recursive compares on large nested objects are now slow, which used to > be fast because default methods wouldn't cause a recursive comparison at > all). But if the default method doesn't do what you want, it doesn't matter how fast it is. Remember that it's very easy to make recursive comparisons, by comparing lists for example, and it hasn't disturbed anyone. To summarize, I think that value-based equality testing would usually be what you want, and currently implementing it is a bit of a pain. Concerning backwards-compatibility: show a warning in Python 2.5 when the default equality test is being made, and change it in Python 2.6. Comments, please! Thanks, Noam [View Less]

6 12

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Nov. 7, 2005

Nov. 7, 2005

Patch / Bug Summary ___________________ Patches : 365 open ( +5) / 2961 closed ( +5) / 3326 total (+10) Bugs : 904 open (+11) / 5367 closed (+14) / 6271 total (+25) RFE : 200 open ( +1) / 189 closed ( +0) / 389 total ( +1) New / Reopened Patches ______________________ new function: os.path.relpath (2005-10-27) http://python.org/sf/1339796 opened by Richard Barran commands.getstatusoutput() (2005-11-02) http://python.org/sf/1346211 opened by Dawa Lama … [View More]

1 0

cross-compiling
by Neal Norwitz Nov. 7, 2005

Nov. 7, 2005

We've been having some issues and discussions at work about cross compiling. There are various people that have tried (are) cross compiling python. Right now the support kinda sucks due to a couple of reasons. First, distutils is required to build all the modules. This means that python must be built twice. Once for the target machine and once for the host machine. The host machine is really not desired since it's only purpose is to run distutils. I don't know the history of why … [View More]

6 6

[OTAnn] Feedback
by shenanigans Nov. 7, 2005

Nov. 7, 2005

I was interested in getting feedback from current mail group users. We have mirrored your mail list in a new application that provides a more aggregated and safe environment which utilizes the power of broadband. Roomity.com v 1.5 is a web 2.01 community webapp. Our newest version adds broadcast video and social networking such as favorite authors and an html editor. It?s free to join and any feedback would be appreciated. S. ---------------------------------------------------------------… [View More]

1 0

For Python 3k, drop default/implicit hash, and comparison
by Jim Fulton Nov. 6, 2005

Nov. 6, 2005

The recent discussion about what the default hash and equality comparisons should do makes me want to chime in. IMO, the provision of defaults for hash, eq and other comparisons was a mistake. I'm especially sensitive to this because I do a lot of work with persistent data that outlives program execution. For such objects, memory address is meaningless. In particular, the default ordering of objects based in address has caused a great deal of pain to people who store data in persistent … [View More]

4 5

Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison
by Phillip J. Eby Nov. 6, 2005

Nov. 6, 2005

At 12:58 PM 11/6/2005 -0800, Guido van Rossum wrote: >The main way this breaks down is when comparing objects of different >types. While most comparisons typically are defined in terms of >comparisons on simpler or contained objects, two objects of different >types that happen to have the same "key" shouldn't necessarily be >considered equal. When I use this pattern, I often just include the object's type in the key. (I call it the 'hashcmp' value, but otherwise it's the same pattern.)

3 2

Why should the default hash(x) == id(x)?
by Noam Raphael Nov. 6, 2005

Nov. 6, 2005

Hello, While writing my PEP about unifying mutable and immutable, I came upon this: Is there a reason why the default __hash__ method returns the id of the objects? It is consistent with the default __eq__ behaviour, which is the same as "is", but: 1. It can easily become inconsistent, if someone implements __eq__ and doesn't implement __hash__. 2. It is confusing: even if someone doesn't implement __eq__, he may see that it is suitable as a key to a dict, and expect it to be found by other … [View More]

5 9

PEP 352 Transition Plan
by Raymond Hettinger Nov. 5, 2005

Nov. 5, 2005

I don't follow why the PEP deprecates catching a category of exceptions in a different release than it deprecates raising them. Why would a release allow catching something that cannot be raised? I must be missing something here. Raymond

7 11

Class decorators vs metaclasses
by Eyal Lotem Nov. 5, 2005

Nov. 5, 2005

I have a few claims, some unrelated, and some built on top of each other. I would like to hear your responses as to which are convincing, which arne't, and why. I think that if these claims are true, Python 3000 should change quite a bit. A. Metaclass code is black magic and few understand how it works, while decorator code is mostly understandable, even by non-gurus. B. One of Decorators' most powerful features is that they can mixed-and-matched, which makes them very powerful for many … [View More]

2 2