On Apr 26, 2:31 pm, John Nagle <na...@animats.com> wrote: > On 4/26/2012 4:45 AM, Adam Skutt wrote: > > On Apr 26, 1:48 am, John Nagle<na...@animats.com> wrote: > >> On 4/25/2012 5:01 PM, Steven D'Aprano wrote: > > >>> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote: > > >>>> Though, maybe it's better to use a different keyword than 'is' though, > >>>> due to the plain English > >>>> connotations of the term; I like 'sameobj' personally, for whatever > >>>> little it matters. Really, I think taking away the 'is' operator > >>>> altogether is better, so the only way to test identity is: > >>>> id(x) == id(y) > > >>> Four reasons why that's a bad idea: > > >>> 1) The "is" operator is fast, because it can be implemented directly by > >>> the interpreter as a simple pointer comparison (or equivalent). > > >> This assumes that everything is, internally, an object. In CPython, > >> that's the case, because Python is a naive interpreter and everything, > >> including numbers, is "boxed". That's not true of PyPy or Shed Skin. > >> So does "is" have to force the creation of a temporary boxed object? > > > That's what C# does AFAIK. Java defines '==' as value comparison for > > primitives and '==' as identity comparison for objects, but I don't > > exactly know how one would do that in Python. > > I would suggest that "is" raise ValueError for the ambiguous cases. > If both operands are immutable, "is" should raise ValueError.
I don't know how you would easily detect user-defined immutable types, nor do I see why such an operation should be an error. I think it would end up violating the principal of least surprise in a lot of cases, especially when talking about things like immutable sets, maps, or other complicated data structures. What I think you want is what I said above: ValueError raised when either operand is a /temporary/ object. Really, it should probably be a parse-time error, since you could (and should) make the determination at parse time. > That's the case where the internal representation of immutables > shows through. You still have this problem with mutable temporary objects, as my little snipped showed. You're still going to get a result that's inconsistent and/or "surprising" sooner or later. The problem is the temporary nature of the object, not mutability. > > If this breaks a program, it was broken anyway. It will > catch bad comparisons like > > if x is 1000 : > ... > > which is implementation dependent. Yes, I agree that a correct fix shouldn't break anything except already broken programs. Adam -- http://mail.python.org/mailman/listinfo/python-list
