why () is () and [] is [] work in other way?
Adam Skutt
askutt at gmail.com
Thu Apr 26 15:34:10 EDT 2012
On Apr 26, 2:31 pm, John Nagle <na... at animats.com> wrote:
> On 4/26/2012 4:45 AM, Adam Skutt wrote:
> > On Apr 26, 1:48 am, John Nagle<na... at 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
More information about the Python-list
mailing list