[Python-Dev] Why should the default hash(x) == id(x)?
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 objects with the same "value". 3. If someone does want to associate values with objects, he can explicitly use id: dct[id(x)] = 3. This seems to better explain what he wants. Now, I just thought of a possible answer: "because he wants to store in his dict both normal objects and objects of his user-defined type, which turn out to be not equal to any other object." 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? I would be happy to get answers. Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > This is just a comment from the peanut gallery, as it's highly unlikely I'll > be in attendance, but why not continue with the AST theme? Instead of > working on the AST branch, you could start to propagate the AST > representation around. For example, you could use the new AST code to > improve/extend/rewrite the optimization steps the compiler currently > performs. Another alternative would be to rewrite Pychecker (or Pychecker > 2) to operate from the AST representation. That's an excellent suggestion. I think I will borrow the time machine and add it to the wiki. :-) It's up on the wiki. Brett also added an item for the peephole optimizer. Everyone should add whatever they think are good ideas, even if they don't plan to attend the sprints. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] apparent ruminations on mutable immutables (was:PEP 351, the freeze protocol)
Josiah Carlson writes: > If you make such a suggestion, I would offer that you create a new PEP, > because this discussion has gone beyond PEP 351, and has wandered into > the realm of "What other kinds of objects would be interesting to have > in a Python-like system?" Noam Raphael replies: > That is a good suggestion, and I have already started to write one. It > takes me a long time, but I hope I will manage. My thanks to both of you... following this conversation has been an educational experience. Just for the record, I wanted to chime in with my own opinion formed after following the full interchange. I think Noam's propsal is very interesting. I like the idea of allowing both "frozen" (ie, immutable) and mutable treatments for the same object. I think that C++'s version of this concept (the "const" modifier) has, on balance, been only a very limited success. I find myself convinced by Noam's claims that many common use patterns either (1) only use mutables, or (2) only use immutables, or (3) only use immutable copies temporarily and avoid mutating while doing so. Any such use patterns (particularly use (3)) would benefit from the presence of an efficient method for creating an immutable copy of a mutable object which avoids the copy where possible. However... it seems to me that what is being described here is not Python. Python is a wonderful language, but it has certain characteristics, like extremely dynamic behavior and close integration with underlying system methods (C in CPython, Java in Jython, etc) that seem to me to make this particular feature a poor fit. That's OK... not all languages need to be Python! I would encourage you (Noam) to go ahead and explore this idea of yours. You might wind up building a new language from scratch (in which case I strongly encourage you to borrow _syntax_ from Python -- its syntax is more usable than that of any other language I know of). Or perhaps you will prefer to take CPython and make minor modifications. This kind of experimentation is allowed (open source) and even encouraged... consider Christian Tismer's Stackless -- a widely admired variant of CPython which is unlikely to ever become part of the core, but is nevertheless an important part of the vivrant Python community. You might even be interested in starting, instead, with PyPy -- an large project which has as its main goal producing an implementation of Python which is easy to modify so as to support just this kind of experimentation. You are also welcome to submit a PEP for modifying Python (presumably CPython, Jython, Iron Python, and all other implementations). However, I think such a PEP would be rejected. Building your own thing that works well with Python would NOT be rejected. The idea is interesting, and it _may_ be sound; only an actual implementation could prove this either way. -- Michael Chermside ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
Noam Raphael writes: > 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 objects with the same "value". > 3. If someone does want to associate values with objects, he can > explicitly use id: > dct[id(x)] = 3. This seems to better explain what he wants. Your first criticism is valid... it's too bad that there isn't a magical __hash__ function that automatically derived its behavior from __eq__. To your second point, I would tell this user to read the requirements. And your third point isn't a criticism, just an alternative. But to answer your question, the reason that the default __hash__ returns the ID in CPython is just that this works. In Jython, I belive that the VM provides a native hash method, and __hash__ uses that instead of returning ID. Actually, it not only works, it's also FAST (which is important... many algorithms prefer that __hash__ being O(1)). I can't imagine what you would propose instead. Keep in mind that the requirements are that __hash__ must return a value which distinguishes the object. So, for instance, two mutable objects with identical values MUST (probably) return different __hash__ values as they are distinct objects. > This leads me to another question: why should the default __eq__ > method be the same as "is"? Another excellent question. The answer is that this is the desired behavior of the language. Two user-defined object references are considered equal if and only if (1) they are two references to the same object, or (2) the user who designed it has specified a way to compare objects (implemented __eq__) and it returns a True value. > 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 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. -- Michael Chermside ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
Noam Raphael <[EMAIL PROTECTED]> wrote: > > 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? A quick search in the list archives via google search "site:mail.python.org object __hash__" Says that Guido wanted to remove the default __hash__ method for object in Python 2.4, but that never actually happened. http://www.python.org/sf/660098 http://mail.python.org/pipermail/python-dev/2003-December/041375.html There may be more code which relies on the default behavior now, but fixing such things is easy. > Now, I just thought of a possible answer: "because he wants to store > in his dict both normal objects and objects of his user-defined type, > which turn out to be not equal to any other object." Which is a use-case, but a use-case which isn't always useful. Great for singleton/default arguments that no one should ever pass, not quite so good when you need the /original key/ (no copies) in order to get at a value in a dictionary - but that could be something that someone wants. > 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 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). As for removing the default __hash__ for objects, I'm actually hovering around a -0, if only because it is sometimes useful to generate unique keys for dictionaries (which can be done right now with object() ), and I acknowledge that it would be easy to subclass and use that instead. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] apparent ruminations on mutable immutables (was:PEP 351, the freeze protocol)
Thank you for your encouraging words! I am currently working on a PEP. I am sure that writing it is a good idea, and that it would help with explaining this idea both to others and to myself. What I already wrote makes me think that it can be accomplished with no really large changes to the language - only six built-in types are affected, and there is no reason why existing code, both in C and in Python, would stop working. I hope others would be interested in the idea too, when I finish writing the PEP draft, so it would be discussed. Trying the idea with PyPy is a really nice idea - it seems that it would be much simpler to implement, and I'm sure that learning PyPy would be interesting. Thanks again, and I would really like to hear your comments when I post the PEP draft, Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Optimizations on the AST representation
Hi, I'm a norwegian applied mathematics student with an interest in compilers, and I've been a long-time python user and a python-dev lurker for some time. I'm very happy that you've integrated the AST branch into mainline, but I noticed that the AST compiler does not perform much optimization yet, so I though I'd take a crack at it. I just submitted the following patches: http://www.python.org/sf/1346214 http://www.python.org/sf/1346238 which adds better dead code elimination and constant folding of the AST representation to Python. The constant folding patch adds two new files, Include/optimize.h and Python/optimize.c, which includes a general visitor interface abstracted from exisiting visitor code for easy optimization pass creation. The code is in new files in order to make room for more AST optimization passes, and since Python/compile.c is already quite crowded with byte code generation and bytecode optimization. If desired, this patch could changed to add code to Python/compile.c instead. Further work: A limited form of type interference (e.g. as a synthesized attribute) could be very useful for further optimizations. Since python allows operator overloading, it isn't safe to perform strength reductions on expressions with operands of unknown type, as there is no way to know if algebraic identities will hold. However, if we can infer from the context that expressions have the type of int, float or long, many optimizations become possible, for instance: x**2 => x*x x*2 => x+x x*0 => 0 x*1 => x 4*x + 5*x => 9*x (this optimization actually requires common subexpression elimination for the general case, but simple cases can be performed without this) and so forth. Another interesting optimization that can potensially bring a lot of additional speed is hoisting of loop invariants, since calling python methods involves allocating and creating a method-wrapper object. An informal test shows that optimizing lst = [] for i in range(10): lst.append(i+1) into lst = [] tmp = lst.append for i in range(10): tmp(i+1) will yield a 10% speed increase. This operation is of course not safe with arbitrary types, but with the above type interference, we could perform this operation if the object is of a type that disallows attribute assignment, for instance lists, tuples, strings and unicode strings. Regards, Rune Holm ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
On 11/2/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: ... > > A quick search in the list archives via google search >"site:mail.python.org object __hash__" > Says that Guido wanted to remove the default __hash__ method for object > in Python 2.4, but that never actually happened. > > http://www.python.org/sf/660098 > http://mail.python.org/pipermail/python-dev/2003-December/041375.html > > There may be more code which relies on the default behavior now, but > fixing such things is easy. > Cool! If Guido also thinks that it should be gone, who am I to argue... (Seriously, I am in favor of removing it. I really think that it is confusing.) And if backwards-compatibility is a problem: You can, in Python 2.5, show a warning when the default __hash__ method is being called, saying that it is going to disappear in Python 2.6. [Snip - I will open a new thread about the equality operator] > As for removing the default __hash__ for objects, I'm actually hovering > around a -0, if only because it is sometimes useful to generate unique > keys for dictionaries (which can be done right now with object() ), and > I acknowledge that it would be easy to subclass and use that instead. > I can suggest a new class, that will help you in the cases that you do want a dict of identities: class ref(object): def __init__(self, obj): self._obj = obj def __call__(self): return self._obj def __eq__(self, other): return self._obj is other._obj def __hash__(self): return hash(id(self._obj)) It has the advantage over using ids as keys, that it saves a reference to the object, so it won't be killed. It lets you make a dict of object identities just as easily as before, in a more explicit and error-prone way. Perhaps it should become a builtin? Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problems with revision 4077 of new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to mirror the brand-new Python SVN repository with SVK, to better be able to track both the trunk and the various branches. Since I'm not a Python developer and don't have svn+ssh access, I'm doing so over http. The process fails when trying to fetch revision 4077, with the following error message: "RA layer request failed: REPORT request failed on 'projects/!svn/bc/41373/python': The REPORT request returned invalid XML in the response: XML parse error at line 7: not well-formed (invalid token) (/projects/!svn/bc/41373/python)" The thread at http://svn.haxx.se/dev/archive-2004-07/0793.shtml suggests that the problem may lie in the commit message for revision 4077: if it has a character in the 0x01-0x1f range (which are invalid XML), then Subversion methods like http: will fail to retrieve it, while methods like file: will succeed. I haven't tried svn+ssh: since I don't have an SSH key on the server. Trying "svn log -r 4077 http://svn.python.org/projects/python/"; also fails: subversion/libsvn_ra_dav/util.c:780: (apr_err=175002) svn: REPORT request failed on '/projects/!svn/bc/4077/python' subversion/libsvn_ra_dav/util.c:760: (apr_err=175002) svn: The REPORT request returned invalid XML in the response: XML parse error at line 7: not well-formed (invalid token) (/projects/!svn/bc/4077/python) When I visit http://svn.python.org/view/python/?rev=4077, I can see the offending log message. Sure enough, there's a 0x1b character in it, between the space after "Added" and the "h" immediately before the word "Moved". This problem can be fixed by someone with root permissions on the SVN server logging in and running the following: echo "New commit message goes here" > new-message.txt svnadmin setlog --bypass-hooks -r 4077 /path/to/repos new-message.txt If there are other, similar problems later in the SVN repository, I was unable to find them because the SVK mirror process consistently halts at revision 4077. If revision 4077 is fixed and I turn up other log problems, I'll report them as well. - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaRd46OLMk9ZJcBQRApjAAJ9K3Y5z1q4TulqwVjmZTZb9ZgY31ACcD8RI fNFmGL2U4XaIKa2n6UUyxEA= =tEbq -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Should the default equality operator compare values instead of identities?
I think it should. (I copy here messages from the thread about the default hash method.) On 11/2/05, Michael Chermside <[EMAIL PROTECTED]> 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 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 <[EMAIL PROTECTED]> 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
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
I've looked for classes in my /usr/lib/python2.4 directory. I won't go over all the 7346 classes that were found there, but let's see: "identity objects" that will continue to work because they contain other "identity objects" SocketServer, and everything which inherits from it (like HTTPServer) Queue csv (contains _csv objects) "value objects" that would probably gain a meaningful equality operator StringIO ConfigParser markupbase, HTMLParser HexBin, BinHex cgi.FieldStorage AST Nodes others == Cookie - inherits from dict its __eq__ method. I'll stop here. I was not strictly scientific, because I chose classes that I thought that I might guess what they do easily, and perhaps discarded classes that didn't look interesting to me. But I didn't have any bad intention when choosing the classes. I have seen no class that the change would damage its equality operator. I have seen quite a lot of classes which didn't define an equality operator, and that a value-based comparison would be the right way to compare them. I'm getting more convinced in my opinion. Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare valuesinstead of identities?
On 11/2/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Should the default equality operator compare valuesinstead of > identities? > > No. Look back into last year's python-dev postings where we agreed that > identity would always imply equality. There were a number of practical > reasons. Also, there are a number of places in CPython where that > assumption is implicit. > Perhaps you've meant something else, or I didn't understand? Identity implying equality is true also in value-based comparison. If the default __eq__ operator compares by value, I would say that it would do something like: def __eq__(self, other): if self is other: return True if type(self) is not type(other): return False (compare the __dict__ and any __slots__, and if they are all ==, return True.) Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with revision 4077 of new SVN repository
Robin Munn wrote: > echo "New commit message goes here" > new-message.txt > svnadmin setlog --bypass-hooks -r 4077 /path/to/repos new-message.txt Thanks for pointing that out, and for giving those instructions. I now corrected the log message. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with revision 4077 of new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: > Robin Munn wrote: > >> echo "New commit message goes here" > new-message.txt >> svnadmin setlog --bypass-hooks -r 4077 /path/to/repos new-message.txt > > > Thanks for pointing that out, and for giving those instructions. > I now corrected the log message. Revision 4077 is fine now. However, the same problem exists in revision 4284, which has a 0x01 character before the word "add". Same solution: echo "New commit message goes here" > new-message.txt svnadmin setlog --bypass-hooks -r 4284 /path/to/repos new-message.txt If there are two errors of the same type within about 200 revisions, there may be more. I'm currently running "svn log" on every revision in the Python SVN repository to see if I find any more errors of this type, so that I don't have to hunt them down one-by-one by rerunning SVK. I'll post my findings when I'm done. - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaUho6OLMk9ZJcBQRAg5eAJ9cJTPKX69DhXJyoT/cDV5GmZlC3QCfRj/E wCix8IYU8xbh5/Ibnpa+kg4= =+jLR -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why should the default hash(x) == id(x)?
Noam Raphael wrote: > 3. If someone does want to associate values with objects, he can > explicitly use id: > dct[id(x)] = 3. This is fragile. Once all references to x are dropped, it is possible for another object to be created having the same id that x used to have. The dict now unintentionally references the new object. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should the default equality operator compare values instead of identities?
Noam Raphael <[EMAIL PROTECTED]> wrote: > On 11/2/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > 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. Right, but lists (dicts, tuples, etc.) are defined as containers, and their comparison operation is defined on their contents. Objects are not defined as containers in the general case, so defining comparisons based on their contents (as opposed to identity) is just one of the two assumptions to be made. I personally like the current behavior, and I see no /compelling/ reason to change it. You obviously feel so compelled for the behavior to change that you are willing to express your desires. How about you do something more productive and produce a patch which implements the changes you want, verify that it passes tests in the standard library, then post it on sourceforge. If someone is similarly compelled and agrees with you (so far I've not seen any public support for your proposal by any of the core developers), the discussion will restart, and it will be decided (not by you or I). > 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. Actually, implementing value-based equality testing, when you have a finite set of values you want to test, is quite easy. def __eq__(self, other): for i in self.__cmp_eq__: if getattr(self, i) != getattr(other, i): return False return True With a simple metaclass that discovers all of those values automatically, and/or your own protocol for exclusion, and you are done. Remember, not all 5-line functions should become builtin/default behavior, and this implementation shows that it is not a significant burdon for you (or anyone else) to implement this in your own custom library. - Josiah P.S. One thing that you should remember is that even if your patch is accepted, and even if this is desireable, Python 2.5 is supposed to be released sometime next year (spring/summer?), and because it is a backwards incompatible change, would need at least 2.6-2.7 before it becomes the default behavior without a __future__ import, which is another 3-4 years down the line. I understand you are passionate, really I do (you should see some of my proposals), but by the time these things get around to getting into mainline Python, there are high odds that you probably won't care about them much anymore (I've come to feel that way myself about many of my proposals), and I think it is a good idea to attempt to balance - when it comes to Python - "Now is better than never." and "Although never is often better than *right* now." Removing __hash__, changing __eq__, and trying to get in copy-on-write freezing (which is really copy-and-cache freezing), all read to me like "We gotta do this now!", which certainly isn't helping the proposal. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with revision 4077 of new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin Munn wrote: > Revision 4077 is fine now. However, the same problem exists in revision > 4284, which has a 0x01 character before the word "add". Same solution: > > echo "New commit message goes here" > new-message.txt > svnadmin setlog --bypass-hooks -r 4284 /path/to/repos new-message.txt > > If there are two errors of the same type within about 200 revisions, > there may be more. I'm currently running "svn log" on every revision in > the Python SVN repository to see if I find any more errors of this type, > so that I don't have to hunt them down one-by-one by rerunning SVK. I'll > post my findings when I'm done. My script is up to revision 17500 with no further problems found; I now believe that 4077 and 4284 were isolated cases. Once 4284 is fixed, it should now be possible to SVK-mirror the entire repository. - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaXJF6OLMk9ZJcBQRAtZpAJ9iE1SlRJiQQOdIuBFuvjmQG3gshACgl9/A vbsGD0bX3NCirQC5qtxdLYo= =sgk/ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with revision 4077 of new SVN repository
Robin Munn wrote: >>Revision 4077 is fine now. However, the same problem exists in revision >>4284, which has a 0x01 character before the word "add". Same solution: I now have fixed that as well. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
