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): return hash(self.s) def __cmp__(self,other): if type(self)==type(other): return cmp(self.s,other.s) if type(other)==str: return cmp(self.s,other) >>> a={} >>> a['s']=1 >>> a[Boo('s')] 1 >>> a[Boo('z')]=2 >>> a['z'] 2 It is confused and hardly usefull, but possible. Excuse my english.

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 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

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 Better dead code elimination for the AST compiler (2005-11-02) http://python.org/sf/1346214 opened by Rune Holm A constant folding optimization pass for the AST (2005-11-02) http://python.org/sf/1346238 opened by Rune Holm Remove inconsistent behavior between import and zipimport (2005-11-03) http://python.org/sf/1346572 opened by Osvaldo Santana Neto Patch f. bug 495682 cannot handle http_proxy with user:pass@ (2005-11-05) CLOSED http://python.org/sf/1349117 opened by Johannes Nicolai Patch f. bug 495682 cannot handle http_proxy with user:pass@ (2005-11-05) http://python.org/sf/1349118 opened by Johannes Nicolai [PATCH] 100x optimization for ngettext (2005-11-06) http://python.org/sf/1349274 opened by Joe Wreschnig Fix for signal related abort in Visual Studio 2005 (2005-11-07) http://python.org/sf/1350409 opened by Adal Chiriliuc Redundant connect() call in logging.handlers.SysLogHandler (2005-11-07) http://python.org/sf/1350658 opened by Ken Lalonde Patches Closed ______________ tarfile.py: fix for bug #1336623 (2005-10-26) http://python.org/sf/1338314 closed by nnorwitz Python 2.4.2 doesn't build with "--without-threads" (2005-10-22) http://python.org/sf/1335054 closed by nnorwitz Speedup PyUnicode_DecodeCharmap (2005-10-05) http://python.org/sf/1313939 closed by lemburg Allow use of non-latin1 chars in interactive shell (2005-10-21) http://python.org/sf/1333679 closed by loewis Patch f. bug 495682 cannot handle http_proxy with user:pass@ (2005-11-05) http://python.org/sf/1349117 closed by birkenfeld New / Reopened Bugs ___________________ CVS webbrowser.py (1.40) bugs (2005-10-27) CLOSED http://python.org/sf/1339806 opened by Greg Couch TAB SETTINGS DONT WORK (win) (2005-10-27) http://python.org/sf/1339883 opened by reson5 time.strptime() with bad % code throws bad exception (2005-10-27) CLOSED http://python.org/sf/1340337 opened by Steve R. Hastings mmap does not accept length as 0 (2005-10-28) http://python.org/sf/1341031 opened by liturgist "\n" is incorrectly represented (2005-10-30) CLOSED http://python.org/sf/1341934 opened by Pavel Tkinter.Menu.delete doesn't delete command of entry (2005-10-30) http://python.org/sf/1342811 opened by Sverker Nilsson Broken docs for os.removedirs (2005-10-31) http://python.org/sf/1343671 opened by David Kågedal UNIX mmap leaks file descriptors (2005-11-01) CLOSED http://python.org/sf/1344508 opened by Erwin S. Andreasen colorsys tests, bug in frange (2005-11-01) CLOSED http://python.org/sf/1345263 opened by Rune Holm Python 2.4 and 2.3.5 won't build on OpenBSD 3.7 (2005-11-01) http://python.org/sf/1345313 opened by Dan doc typo (2005-11-02) CLOSED http://python.org/sf/1346026 opened by Keith Briggs Segfaults from unaligned loads in floatobject.c (2005-11-02) http://python.org/sf/1346144 opened by Rune Holm Missing import in documentation (2005-11-03) CLOSED http://python.org/sf/1346395 opened by Aggelos Orfanakos selectmodule.c calls PyInt_AsLong without error checking (2005-11-03) CLOSED http://python.org/sf/1346533 opened by Luke _subprocess.c calls PyInt_AsLong without error checking (2005-11-03) http://python.org/sf/1346547 opened by Luke httplib simply ignores CONTINUE (2005-11-03) http://python.org/sf/1346874 opened by Mike Looijmans FeedParser does not comply with RFC2822 (2005-11-04) http://python.org/sf/1347874 opened by Julian Phillips pydoc seems to run some scripts! (2005-11-04) http://python.org/sf/1348477 opened by Olly Betts email.Generators does not separates headers with "\r\n" (2005-11-05) http://python.org/sf/1349106 opened by Manlio Perillo xmlrpclib does not use http proxy (2005-11-06) http://python.org/sf/1349316 opened by greatred urllib.urlencode provides two features in one param (2005-11-06) http://python.org/sf/1349732 opened by Ori Avtalion urllib2 blocked from news.google.com (2005-11-07) CLOSED http://python.org/sf/1349977 opened by Michael Hoisie built-in method .__cmp__ (2005-11-07) http://python.org/sf/1350060 opened by Armin Rigo "setdlopenflags" leads to crash upon "import" (2005-11-07) http://python.org/sf/1350188 opened by John Pye CVS migration not in www.python.org docs (2005-11-07) http://python.org/sf/1350498 opened by Jim Jewett zlib.crc32 doesn't handle 0xffffffff seed (2005-11-07) http://python.org/sf/1350573 opened by Danny Yoo Bugs Closed ___________ CVS webbrowser.py (1.40) bugs (2005-10-27) http://python.org/sf/1339806 deleted by gregcouch Memory keeping (2005-10-26) http://python.org/sf/1338264 closed by tim_one tarfile can't extract some tar archives.. (2005-10-24) http://python.org/sf/1336623 closed by nnorwitz time.strptime() with bad % code throws bad exception (2005-10-27) http://python.org/sf/1340337 closed by bcannon _socket module not build under cygwin (2005-09-22) http://python.org/sf/1298709 closed by jlt63 "\n" is incorrectly represented (2005-10-30) http://python.org/sf/1341934 closed by perky pydoc HTTP reload failure (2001-04-21) http://python.org/sf/417833 closed by ping UNIX mmap leaks file descriptors (2005-10-31) http://python.org/sf/1344508 closed by nnorwitz colorsys tests, bug in frange (2005-11-01) http://python.org/sf/1345263 closed by nnorwitz Python.h should include system headers properly [POSIX] (2005-10-25) http://python.org/sf/1337400 closed by loewis doc typo (2005-11-02) http://python.org/sf/1346026 closed by nnorwitz Missing import in documentation (2005-11-02) http://python.org/sf/1346395 closed by bcannon selectmodule.c calls PyInt_AsLong without error checking (2005-11-02) http://python.org/sf/1346533 closed by nnorwitz pydoc ignores $PAGER if TERM='dumb' (2002-12-09) http://python.org/sf/651124 closed by ping urllib2 blocked from news.google.com (2005-11-06) http://python.org/sf/1349977 closed by bcannon New / Reopened RFE __________________ please support the free visual studio sdk compiler (2005-11-04) http://python.org/sf/1348719 opened by David McNab

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 distutils is used. I haven't had much of an issue with it since I've never needed to cross compile. What are the issues with not requiring python to be built on the host machine (ie, not using distutils)? Second, in configure we try to run little programs (AC_TRY_RUN) to determine what to set. I don't know of any good alternative but to force those to be defined manually for cross-compiled environments. Any suggestions here? I'm thinking we can skip the the AC_TRY_RUNs if host != target and we pickup the answers to those from a user supplied file. I'm *not* suggesting that normal builds see any change in behaviour. Nothing will change for most developers. ie, ./configure ; make ; ./python will continue to work the same. I only want to make it possible to cross compile python by building it only on the target platform. n PS. I would be interested to hear from others who are doing cross compiling and know more about it than me.

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. -------------------------------------------------------------------------------------------------------------------------------------------------- Broadband interface (RIA) + mail box saftey = <a href="http://Python_Core_Developers_List.roomity.com">Python_Core_Developers_List.roomity.com</a> *Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131397871425~~ --------------------------------------------------------------------------------------------------------------------------------------------------

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 BTrees. Oddly, what I've read in these threads seems to be arguing about which implicit method is best. The answer, IMO, is to not do this implicitly at all. If programmers want their objects to be hashable, comparable, or orderable, then they should implement operators explicitly. There could even be a handy, but *optional*, base class that provides these operators based on ids. This would be too big a change for Python 2 but, IMO, should definately be made for Python 3k. I doubt any change in the default definition of these operations is practical for Python 2. Too many people rely on them, usually without really realizing it. Lets plan to stop guessing how to do hash and comparison. Explicit is better than implicit. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

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 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

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 purposes, while metaclasses are exclusive, and only one can be used. This is especially problematic as some classes may assume their subclasses must use their respective metaclasses. This means classdecorators are strictly more powerful than metaclasses, without cumbersome convertions between metaclass mechanisms and decorator mechanisms. C. Interesting uses of classdecorators are allowing super-calling without redundantly specifying the name of your class, or your superclass. D. Python seems to be incrementally adding power to the core language with these features, which is great, but it also causes significant overlapping of language features, which I believe is something to avoid when possible. If metaclasses are replaced with class decorators, then suddenly inheritence becomes a redundant feature. E. If inheritence is a redundant feature, it can be removed and an "inherit" class decorator can be used. This could also reduce all the __mro__ clutter from the language along with other complexities, into alternate implementations of the inherit classdecorator.

2 2