Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

why () is () and [] is [] work in other way?

 

 

First page Previous page 1 2 3 4 5 6 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded


nagle at animats

Apr 25, 2012, 10:48 PM

Post #76 of 142 (2041 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

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?

The concept of "object" vs. the implementation of objects is
one reason you don't necessarily want to expose the implementation.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list


rosuav at gmail

Apr 25, 2012, 11:36 PM

Post #77 of 142 (2040 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Thu, Apr 26, 2012 at 3:48 PM, John Nagle <nagle [at] animats> wrote:
> 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?

Interesting point. Presumably the only types that can be unboxed are
those for which identity vs equality is pretty much immaterial, so the
question won't really matter. I'd be inclined to either have it return
False if either/both is unboxed, or else return True if both are equal
unboxed numbers, whichever is the most convenient to implement.

My opinion doesn't matter--
My opinion doesn't matter--
My opinion doesn't matter, matter, matter, matter, matter!
(WS Gilbert, "Ruddigore")

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list


steve+comp.lang.python at pearwood

Apr 26, 2012, 1:40 AM

Post #78 of 142 (2048 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Wed, 25 Apr 2012 22:48:33 -0700, John Nagle 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.

No it doesn't. It assumes that everything provides the external interface
of an object. Internally, the implementation could be anything you like,
so long as it simulates an object when observed from Python.


--
Steven
--
http://mail.python.org/mailman/listinfo/python-list


steve+comp.lang.python at pearwood

Apr 26, 2012, 2:10 AM

Post #79 of 142 (2047 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Wed, 25 Apr 2012 20:50:21 -0700, Adam Skutt wrote:

> On Apr 25, 8:01 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> 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). The
>> id() idiom is slow, because it involves two global lookups and an
>> equality comparison. Inside a tight loop, that can make a big
>> difference in speed.
>
> The runtime can optimize the two operations to be equivalent, since they
> are logically equivalent operations. If you removed 'is', there's
> little reason to believe it would do otherwise.

I'm afraid you are mistaken there. *By design*, Python allows shadowing
and monkey-patching of built-ins. (Although not quite to the same degree
as Ruby, and thank goodness!)

Given the language semantics of Python, "id(a) == id(b)" is NOT
equivalent to "a is b" since the built-in id() function can be shadowed
by some other function at runtime, but the "is" operator cannot be.

An extremely clever optimizing implementation like PyPy may be able to
recognise at runtime that the built-in id() is being called, but that
doesn't change the fact that PyPy MUST support this code in order to
claim to be a Python compiler:

id = lambda x: 999
id(None) == id("spam") # returns True

If your runtime doesn't allow that, it isn't Python.


>> 2) The "is" operator always has the exact same semantics and cannot be
>> overridden. The id() function can be monkey-patched.
>>
>>
> I can't see how that's useful at all. Identity is a fundamental
> property of an object; hence retrieval of it must be a language
> operation. The fact Python chooses to do otherwise is unfortunate, but
> also irrelevant to my position.

It's useful for the same reason that shadowing any other builtin is
useful. id() isn't special enough to complicate the simple, and
effective, execution model just to satisfy philosophers.


>> 3) The "is" idiom semantics is direct: "a is b" directly tests the
>> thing you want to test, namely whether a is b. The id() idiom is
>> indirect: "id(a) == id(b)" only indirectly tests whether a is b.
>
> The two expressions are logically equivalent, so I don't see how this
> matters, nor how it is true.

They are not *logically* equivalent. First you have to define what you
mean by identity, then you have to define what you mean by an ID, and
then you have to decide whether or not to enforce the rule that identity
and IDs are 1:1 or not, and if so, under what circumstances. My library
card ID may, by coincidence, match your drivers licence ID. Doesn't mean
we're the same person. Entities may share identities, or may have many
identities. The Borg design pattern, for example, would be an excellent
candidate for ID:identity being treated as many-to-one.

Even if you decide that treating IDs as 1:1 is the only thing that makes
sense in your philosophy, in practice that does not hold for Python. IDs
may be reused by Python. There are circumstances where different objects
get the same ID. Hence, comparing IDs is not equivalent to identity
testing.

But I was actually referring to something more fundamental than that. The
statement "a is b" is a *direct* statement of identity. "John is my
father." "id(a) == id(b)" is *indirect*: "The only child of John's
grandfather is the parent of the mother-in-law of my sister-in-law" sort
of thing. (Excuse me if I got the relationships mixed up.)


>> 4) The id() idiom already breaks if you replace names a, b with
>> expressions:
>>
>> >>> id([1,2]) == id([3,4])
>> True
>
> It's not broken at all.

It is broken in the sense that "id(a) == id(b)" is to be treated as
equivalent to "a is b". The above example demonstrates that you CANNOT
treat them as equivalent.


[...]
> The other solution is to do what Java and C# do: banish id() entirely

Solution to *what problem*?

I do not believe that there is a problem here that needs to be solved.
Both id() and "is" are perfectly fine for what they do.


>> But that's absolutely wrong. id(x) returns an ID, not an address. It
>> just
>> happens that, as an accident of implementation, the CPython interpreter
>> uses the object address as an ID, because objects can't move. That's
>> not the case for all implementations. In Jython, objects can move and
>> the address is not static, and so IDs are assigned on demand starting
>> with 1:
>>
>> steve [at] rune:~$ jython
>> Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19) [OpenJDK Client VM
>> (Sun Microsystems Inc.)] on java1.6.0_18 Type "help", "copyright",
>> "credits" or "license" for more information.>>> id(42) 1
>> >>> id("Hello World!")
>> 2
>> >>> id(None)
>>
>> 3
>>
>>
> An address is an identifier: a number that I can use to access a
> value[1].

Then by your own definition, Python's id() does not return an address,
since you cannot use it to access a value.




--
Steven
--
http://mail.python.org/mailman/listinfo/python-list


askutt at gmail

Apr 26, 2012, 4:42 AM

Post #80 of 142 (2037 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 5:10am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Wed, 25 Apr 2012 20:50:21 -0700, Adam Skutt wrote:
> > On Apr 25, 8:01pm, Steven D'Aprano <steve
> > +comp.lang.pyt...@pearwood.info> 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). The
> >> id() idiom is slow, because it involves two global lookups and an
> >> equality comparison. Inside a tight loop, that can make a big
> >> difference in speed.
>
> > The runtime can optimize the two operations to be equivalent, since they
> > are logically equivalent operations. If you removed 'is', there's
> > little reason to believe it would do otherwise.
>
> I'm afraid you are mistaken there. *By design*, Python allows shadowing
> and monkey-patching of built-ins. (Although not quite to the same degree
> as Ruby, and thank goodness!)
>
Yes, I understand that. You still haven't explained why this behavior
is correct in this particular situation. Arguing from the position
of, "What Python does must be correct" isn't a valid tactic, I'm
afraid.

> It's useful for the same reason that shadowing any other builtin is
> useful. id() isn't special enough to complicate the simple, and
> effective, execution model just to satisfy philosophers.

If overriding id() is useful, then overriding 'is' must be useful
too. Python is still broken. Unless you can prove the two operations
shouldn't be logically equivalent (and you don't), you can't
meaningfully argue for different semantics for them. You still end up
with a broken language either way.

> They are not *logically* equivalent. First you have to define what you
> mean by identity, then you have to define what you mean by an ID, and
> then you have to decide whether or not to enforce the rule that identity
> and IDs are 1:1 or not, and if so, under what circumstances.

You're going to have to explain the value of an "ID" that's not 1:1
with an object's identity, for at least the object's lifecycle, for a
programmer. If you can't come up with a useful case, then you haven't
said anything of merit.

Plainly, to show they're not logically equivalent, you need to explain
why the guarantee provided by id() is improper. Then, you need to
generalize it to all programming languages. Python's concept of
identity is not unique nor special. It uses the exact same rules as C+
+, C#, Java, and many other languages.

> My library
> card ID may, by coincidence, match your drivers licence ID. Doesn't mean
> we're the same person.

I don't know why you even remotely think this is relevant. All it
does is further demonstrate that you don't understand the object-
oriented concept of identity at all. Comparing library IDs and
drivers license IDs is an improper operation. Languages that can have
multiple IDs, possibly overlapping, /do/ disallow such idiocy.

> identities. The Borg design pattern, for example, would be an excellent
> candidate for ID:identity being treated as many-to-one.

How would inheritance work if I did that?

> Even if you decide that treating IDs as 1:1 is the only thing that makes
> sense in your philosophy, in practice that does not hold for Python. IDs
> may be reused by Python.

They may be reused in all languages I can think of. They're only
unique for the lifetime of the object, because that's all we need as
programmers.

> There are circumstances where different objects
> get the same ID. Hence, comparing IDs is not equivalent to identity
> testing.

Two objects only get the same ID if one of the objects is dead. The
results of such an comparison are obviously meaningless. Some
runtimes even try very hard to prevent you from doing such silly
things.

>
> But I was actually referring to something more fundamental than that. The
> statement "a is b" is a *direct* statement of identity. "John is my
> father." "id(a) == id(b)" is *indirect*: "The only child of John's
> grandfather is the parent of the mother-in-law of my sister-in-law" sort
> of thing. (Excuse me if I got the relationships mixed up.)

Again, the fact that you somehow think this absurd family tree is
relevant only shows you're fundamentally confused about what object
oriented identity means. That's rather depressing, seeing as I've
given you a link to the definition.

In a mathematical sense, you're saying that given f(x) = x+2, using
f(x) is somehow more "direct" (whatever the hell that even means) than
using 'x+2'. That's just not true. We freely and openly interchange
them all the time doing mathematics. Programming is no different.

> It is broken in the sense that "id(a) == id(b)" is to be treated as
> equivalent to "a is b". The above example demonstrates that you CANNOT
> treat them as equivalent.

They give different results, yes, and that's unfortunate. However, my
code clearly demonstrates they are logically equivalent operations:
the temporaries have different addresses in these cases. Both
expressions return the correct answer based on their inputs.

Since there are side-effects involved here, you cannot simply compare
the results and conclude they are different. You must account for the
side-effects, and when you do, then we conclude they have the same
semantics.

> Solution to *what problem*?
>
This confusion that many people have over what 'is' does, including
yourself.

> > An address is an identifier: a number that I can use to access a
> > value[1].
>
> Then by your own definition, Python's id() does not return an address,
> since you cannot use it to access a value.

The fact Python lacks explicit dereferencing doesn't change the fact
that id() returns an address. Replace 'can' with 'could' or 'could
potentially' or the whole phrase with 'represents' if you wish. It's
a rather pointless thing to quibble over.

Would you call the result of casting a C pointer to an int an
address? If so, you must call the result of id() an address as well--
you can't dereference either of them. If not, then you need to
provide an alternate name for the result of casting a C pointer to an
int.

Adam
--
http://mail.python.org/mailman/listinfo/python-list


askutt at gmail

Apr 26, 2012, 4:45 AM

Post #81 of 142 (2047 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 1:48am, 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.

Adam
--
http://mail.python.org/mailman/listinfo/python-list


rosuav at gmail

Apr 26, 2012, 4:56 AM

Post #82 of 142 (2044 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Thu, Apr 26, 2012 at 9:42 PM, Adam Skutt <askutt [at] gmail> wrote:
> Would you call the result of casting a C pointer to an int an
> address? If so, you must call the result of id() an address as well--
> you can't dereference either of them. If not, then you need to
> provide an alternate name for the result of casting a C pointer to an
> int.

It's an address. You can cast it back to pointer and then dereference
it. But you're talking about C, which is portable assembly language.
When I write C code, I expect to be able to shoot myself in the foot
in numerous ways. With Python, you have to actually work at it a bit,
like:

len = str

Okay, that wasn't very hard, but still, it's not like dereferencing an
uninitialized pointer!

But all this is predicated on a few things:

1) The CPU addresses memory by numbers of a certain size.
2) The C declaration "int *ptr" represents an address
3) The C declaration "(int)ptr" turns that address into an integer
that's big enough to store it

Assuming #3 to be correct is a major cause of trouble, but let's
suppose for the moment that it is. What we have is a direct 1:1
relationship between pointers, integers, and object identities. The
fact is, though, that Python does not ever guarantee this.

Side point: In Python 2, id() returns an int, not a long. Is it
possible to be running Python on a 64-bit machine with a 32-bit int
type? And if so, what does CPython do? Return the address modulo 4G?
Because that could result in collisions.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list


robert.kern at gmail

Apr 26, 2012, 5:12 AM

Post #83 of 142 (2047 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On 4/26/12 12:56 PM, Chris Angelico wrote:

> Side point: In Python 2, id() returns an int, not a long. Is it
> possible to be running Python on a 64-bit machine with a 32-bit int
> type?

Yes. Win64 has 64-bit pointers and 32-bit C longs (and thus 32-bit Python ints).

> And if so, what does CPython do? Return the address modulo 4G?

It returns a Python long.

Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxint
2147483647
>>> id('Hello')
30521584L

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list


kiuhnm03.4t.yahoo.it at mail

Apr 26, 2012, 5:17 AM

Post #84 of 142 (2045 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On 4/26/2012 2:01, 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). The id()
> idiom is slow, because it involves two global lookups and an equality
> comparison. Inside a tight loop, that can make a big difference in speed.
>
> 2) The "is" operator always has the exact same semantics and cannot be
> overridden. The id() function can be monkey-patched.
>
> 3) The "is" idiom semantics is direct: "a is b" directly tests the thing
> you want to test, namely whether a is b. The id() idiom is indirect:
> "id(a) == id(b)" only indirectly tests whether a is b.
>
> 4) The id() idiom already breaks if you replace names a, b with
> expressions:
>
>>>> id([1,2]) == id([3,4])
> True

You forgot one:
5) It would be a pain to write (and read)
if id(my_obj) == id(None)
and so anyone would come up with his/her own same_as(),
identical_to(), same_inst() and so on...

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list


rosuav at gmail

Apr 26, 2012, 5:39 AM

Post #85 of 142 (2036 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Thu, Apr 26, 2012 at 10:12 PM, Robert Kern <robert.kern [at] gmail> wrote:
> Yes. Win64 has 64-bit pointers and 32-bit C longs (and thus 32-bit Python
> ints).
>
> It returns a Python long.

Ah, that solves that one. Definite improvement in Python 3 with the
merging of the two types, though. Machine integers are simply a
performance optimization for small values.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list


arnodel at gmail

Apr 26, 2012, 5:40 AM

Post #86 of 142 (2043 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On 26 April 2012 12:42, Adam Skutt <askutt [at] gmail> wrote:
> On Apr 26, 5:10 am, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> On Wed, 25 Apr 2012 20:50:21 -0700, Adam Skutt wrote:
>> > On Apr 25, 8:01 pm, Steven D'Aprano <steve
>> > +comp.lang.pyt...@pearwood.info> wrote:
>> >> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>> >>> [Sterile pedantry]
>> >> [More sterile pedantry]
>> > [Yet more sterile pedantry]
>> [And more]
> [Record breaking levels of sterile pedantry]

Please stop! Steven, I've learnt a lot from your posts on this list
over the years, but too often you spoil it with your compulsion to
have the last word on every argument you get involved in at any cost.
Some arguments aren't worth winning...

--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list


kiuhnm03.4t.yahoo.it at mail

Apr 26, 2012, 6:37 AM

Post #87 of 142 (2058 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On 4/26/2012 13:45, 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.

Why should we take from Java one of its worst misfeatures and disfigure
Python for life?
a==b compares references while a.equals(b) compares values. Really???
Come on...
Python's way is much much cleaner.

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list


askutt at gmail

Apr 26, 2012, 7:00 AM

Post #88 of 142 (2039 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 9:37am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 4/26/2012 13:45, 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.
>
> Why should we take from Java one of its worst misfeatures and disfigure
> Python for life?

There are a lot of misfeatures in Java. Lack of operating overloading
really isn't one of them. I prefer languages that include operator
overloading, but readily understand and accept the arguments against
it. Nor is the differing behavior for '==' between primitives and
objects a misfeature.

C# and Python do have a misfeature: '==' is identity comparison only
if operator== / __eq__ is not overloaded. Identity comparison and
value comparison are disjoint operations, so it's entirely
inappropriate to combine them.

I don't necessarily mind if the two operations have the same symbol,
as long as there's some other way in-context to determine which
operation is occurring. This is the case in C and C++, for example.

> Python's way is much much cleaner.

Nope. Automatically substituting identity equality for value equality
is wrong. While rare, there are legitimate reasons for the former to
be True while the latter is False. Moreover, it means that class
authors must remember to write an __eq__ when appropriate and won't
get any sort of error when they forget to do so. That can lead to
bugs.

Adam
--
http://mail.python.org/mailman/listinfo/python-list


rustompmody at gmail

Apr 26, 2012, 7:18 AM

Post #89 of 142 (2043 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 4:42pm, Adam Skutt <ask...@gmail.com> wrote:
>
> In a mathematical sense, you're saying that given f(x) = x+2, using
> f(x) is somehow more "direct" (whatever the hell that even means) than
> using 'x+2'. That's just not true. We freely and openly interchange
> them all the time doing mathematics. Programming is no different.

If f(x) and x+2 are freely interchangeable then you have referential
transparency, a property that only purely functional languages have.
In python:
>>> a = [1,2]
>>> m1 = [a, a]
>>> m2 = [[1,2],[1,2]]

may make m1 and m2 seem like the same until you assign to m1[0][0].
eg One would not be able to distinguish m1 and m2 in Haskell.

On the whole I whole-heartedly agree that 'a is b' be replaced by
id(a) == id(b), with id itself replaced by something more obviously
implementational like addrof.

The reasons are fundamental: The word 'is' is arguably the primal
existential verb. Whereas 'is' in python is merely a leakage of
implementation up to the programmer level:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Such a leakage may be justified just as C allowing inline asm may be
justified.
However dignifying such a leakage with the primal existential verb
causes all the confusions seen on this thread (and the various
stackoverflow questions etc).

--
http://mail.python.org/mailman/listinfo/python-list


rosuav at gmail

Apr 26, 2012, 7:36 AM

Post #90 of 142 (2041 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Fri, Apr 27, 2012 at 12:00 AM, Adam Skutt <askutt [at] gmail> wrote:
> C# and Python do have a misfeature: '==' is identity comparison only
> if operator== / __eq__ is not overloaded. Identity comparison and
> value comparison are disjoint operations, so it's entirely
> inappropriate to combine them.

So what should happen if you don't implement __eq__? Should the ==
operator throw an exception? This can be done fairly easily:

class object(object):
def __eq__(self,other):
raise NoYouDontException("Naughty programmer, mustn't do that!")

(Works only if you always explicitly subclass object, even though
that's not necessary in Python 3.)

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list


askutt at gmail

Apr 26, 2012, 7:44 AM

Post #91 of 142 (2045 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 10:18am, rusi <rustompm...@gmail.com> wrote:
> On Apr 26, 4:42pm, Adam Skutt <ask...@gmail.com> wrote:
>
>
>
> > In a mathematical sense, you're saying that given f(x) = x+2, using
> > f(x) is somehow more "direct" (whatever the hell that even means) than
> > using 'x+2'. That's just not true. We freely and openly interchange
> > them all the time doing mathematics. Programming is no different.
>
> If f(x) and x+2 are freely interchangeable then you have referential
> transparency, a property that only purely functional languages have.
> In python:

I think you misunderstood what I was trying to explain. Steven is
trying to claim that there's some sort of meaningful difference
between calling an operation/algorithm/function by some name versus
handing out its definition. I was merely pointing out that we
routinely substitute the two when it is appropriate to do so.

My apologies if you somehow took that to mean that I was implying
there was referential transparency here. I couldn't think of a better
example for what I was trying to say.

Adam
--
http://mail.python.org/mailman/listinfo/python-list


kiuhnm03.4t.yahoo.it at mail

Apr 26, 2012, 9:02 AM

Post #92 of 142 (2042 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On 4/26/2012 16:00, Adam Skutt wrote:
> On Apr 26, 9:37 am, Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>> On 4/26/2012 13:45, 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.
>>
>> Why should we take from Java one of its worst misfeatures and disfigure
>> Python for life?
>
> There are a lot of misfeatures in Java. Lack of operating overloading
> really isn't one of them. I prefer languages that include operator
> overloading, but readily understand and accept the arguments against
> it. Nor is the differing behavior for '==' between primitives and
> objects a misfeature.

The fact that you think that that's "differing behaviour" is what makes
it a misfeature. The fact that you think that '==' can take objects as
operands confirms that Java *does* confuse programmers.

> C# and Python do have a misfeature: '==' is identity comparison only
> if operator== / __eq__ is not overloaded. Identity comparison and
> value comparison are disjoint operations, so it's entirely
> inappropriate to combine them.

They're not "disjoint", in fact one almost always implies the other (*).
Python's idea is that, by default, any object is equal to itself and
only itself. The fact that this is equivalent to "identity comparison"
is just a coincidence, from a conceptual point of view.
(*) nan == nan is false, but, at least conceptually, a 'NotComparable'
exception should be raised instead. That wouldn't be very useful, though.

> I don't necessarily mind if the two operations have the same symbol,
> as long as there's some other way in-context to determine which
> operation is occurring. This is the case in C and C++, for example.
>
>> Python's way is much much cleaner.
>
> Nope. Automatically substituting identity equality for value equality
> is wrong. While rare, there are legitimate reasons for the former to
> be True while the latter is False.

There shouldn't be, to be fair.

> Moreover, it means that class
> authors must remember to write an __eq__ when appropriate and won't
> get any sort of error when they forget to do so. That can lead to
> bugs.

I can agree on that, but that's something you can solve with a minor
modification to the language. What I was talking about is the core
design of Java and Python.

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list


driscoll at cs

Apr 26, 2012, 9:05 AM

Post #93 of 142 (2044 views)
Permalink
Re: Re: why () is () and [] is [] work in other way? [In reply to]

This thread has already beaten a dead horse enough that the horse came
back as a zombie and was re-killed, but I couldn't help but respond to
this part:


On 01/-10/-28163 01:59 PM, Adam Skutt wrote:
> Code that relies on the identity of a temporary object is generally
> incorrect. This is why C++ explicitly forbids taking the address
> (identity) of temporaries.

Except that C++ *doesn't* really forbid taking the address of a
temporary, at least indirectly:

#include <iostream>

int const * address_of(int const & x) {
return &x;
}

int main() {
std::cout << address_of(1+2) << "\n";
}

That complies without warning with GCC 4.6 '-Wall -Wextra', MSVC 2010
'/W4', and Comeau's online front end, and I am pretty confident that the
above code is perfectly legal in terms of provoking undefined behavior
(in the technical C++ sense of "your program is now allowed to set your
cat on fire").

Evan
--
http://mail.python.org/mailman/listinfo/python-list


ian.g.kelly at gmail

Apr 26, 2012, 10:04 AM

Post #94 of 142 (2049 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Thu, Apr 26, 2012 at 3:10 AM, Steven D'Aprano
<steve+comp.lang.python [at] pearwood> wrote:
> But I was actually referring to something more fundamental than that. The
> statement "a is b" is a *direct* statement of identity. "John is my
> father." "id(a) == id(b)" is *indirect*: "The only child of John's
> grandfather is the parent of the mother-in-law of my sister-in-law" sort
> of thing. (Excuse me if I got the relationships mixed up.)

I might have used a different example:

1) "John is my father."
2) "John has the same social security number as my father."

The first is concise and clearly expresses the intended statement of identity.
The second could be read to imply any number of things: "John is my
father." "Somebody at the SSA messed up and gave John the same SSN as
my father." "John is an identity thief."

If the assertion I'm trying to express is that John is my father, then
the direct statement #1 is the best way to convey that, at least in
English. Likewise, "a is b" more clearly expresses the intended
comparison than does "id(a) == id(b)".
--
http://mail.python.org/mailman/listinfo/python-list


rustompmody at gmail

Apr 26, 2012, 10:34 AM

Post #95 of 142 (2043 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 7:44pm, Adam Skutt <ask...@gmail.com> wrote:
> On Apr 26, 10:18am, rusi <rustompm...@gmail.com> wrote:
>
> > On Apr 26, 4:42pm, Adam Skutt <ask...@gmail.com> wrote:
>
> > > In a mathematical sense, you're saying that given f(x) = x+2, using
> > > f(x) is somehow more "direct" (whatever the hell that even means) than
> > > using 'x+2'. That's just not true. We freely and openly interchange
> > > them all the time doing mathematics. Programming is no different.
>
> > If f(x) and x+2 are freely interchangeable then you have referential
> > transparency, a property that only purely functional languages have.
> > In python:
>
> I think you misunderstood what I was trying to explain. Steven is
> trying to claim that there's some sort of meaningful difference
> between calling an operation/algorithm/function by some name versus
> handing out its definition. I was merely pointing out that we
> routinely substitute the two when it is appropriate to do so.
>
> My apologies if you somehow took that to mean that I was implying
> there was referential transparency here. I couldn't think of a better
> example for what I was trying to say.
>
> Adam

And my apologies... I forgot to state my main point:
Programmer accessible object identity is the principal impediment to
referential transparency.
In a functional language one can bind a name to a value -- period.
There is nothing more essence-ial -- its platonic id -- to the name
than that and so the whole can of worms connected with object identity
remains sealed within the language implementation.
--
http://mail.python.org/mailman/listinfo/python-list


tjreedy at udel

Apr 26, 2012, 11:14 AM

Post #96 of 142 (2045 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On 4/26/2012 1:48 AM, John Nagle wrote:

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

Python Language Reference
"3.1. Objects, values and types
Objects are Python’s abstraction for data. All data in a Python program
is represented by objects or by relations between objects. ...
Every object has an identity, a type and a value. An object’s identity
never changes once it has been created; ... The ‘is‘ operator compares
the identity of two objects; the id()function* returns an integer
representing its identity#." [notes added]

* the built-in function bound to 'id' on startup.
# and that integer must not change for the lifetime of the object.

None of the above is CPython implementation detail.

What the spec 'forces' is observable behavior. Internal shortcuts are
allowed. If an interpreter 'knows' that 'a' represents anything other
than None, than it can evaluate 'a is None' as False without boxing 'a'
anymore than it is already.

The object model above allows for an object to represent or consist of a
collection of raw, non-object internal data fields. A list is a sequence
of Python objects. A string is not; it is a sequence of 'characters' or
'bytes'. Structs and arrays, including numpy arrays, are similar in
containing non-object values. However, when single characters, bytes, or
other binary values are extracted and exposed to Python code by indexing
or iteration, they must be objectivized (or at least are in CPython).

Worrying about 'is' and 'id' forcing objectness is misplaced. Except for
comparing an object to a pre-defined constant or sentinel, 'is' is
mainly used for introspection and testing. The main use of 'id()' is to
make unambiguous string representations of functions, classes, and modules.

The real 'culprits' for (potentially) forcing objectness are everyday
indexing and iteration. Numpy avoids boxing internal binary values by
providing functions that operate on numpy arrays *without* exposing the
internal values at the Python level. I believe that psycho and now pypy
can analyze a function to determine whether machine ints and floats can
used without being boxed,

--
Terry Jan Reedy


--
http://mail.python.org/mailman/listinfo/python-list


nagle at animats

Apr 26, 2012, 11:31 AM

Post #97 of 142 (2040 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

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.
That's the case where the internal representation of immutables
shows through.

If this breaks a program, it was broken anyway. It will
catch bad comparisons like

if x is 1000 :
...

which is implementation dependent.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list


askutt at gmail

Apr 26, 2012, 11:54 AM

Post #98 of 142 (2046 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 12:02 pm, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 4/26/2012 16:00, Adam Skutt wrote:
> > On Apr 26, 9:37 am, Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
> >> On 4/26/2012 13:45, Adam Skutt wrote:
>
> >>> On Apr 26, 1:48 am, John Nagle<na...@animats.com> wrote:
> >>>> 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.
>
> >> Why should we take from Java one of its worst misfeatures and disfigure
> >> Python for life?
>
> > There are a lot of misfeatures in Java. Lack of operating overloading
> > really isn't one of them. I prefer languages that include operator
> > overloading, but readily understand and accept the arguments against
> > it. Nor is the differing behavior for '==' between primitives and
> > objects a misfeature.
>
> The fact that you think that that's "differing behaviour" is what makes
> it a misfeature. The fact that you think that '==' can take objects as
> operands confirms that Java *does* confuse programmers.
>

The equality operator can absolutely be used between two objects. Try
it if you don't believe me. It always does identity comparison when
given two objects. It can also be given two primitives, and in this
case, it does value comparison. Despite performing different
operations with the same symbol, there's little risk of confusion
because I can trivially figure out if a variable is an object or an
primitive.

> > C# and Python do have a misfeature: '==' is identity comparison only
> > if operator== / __eq__ is not overloaded. Identity comparison and
> > value comparison are disjoint operations, so it's entirely
> > inappropriate to combine them.
>
> They're not "disjoint", in fact one almost always implies the other (*).

"Almost always" isn't a rebuttal. There's no requirement whatsoever
for the results of identity comparison to be related to the results of
value comparison, ergo they are disjoint. Changing one doesn't have
to influence the other. Please note that I never advocated doing what
Java does, I merely noted what it does.

> Python's idea is that, by default, any object is equal to itself and
> only itself.

Which is just wrong-headed. Many types have no meaningful definition
for value equality, ergo any code that attempts to perform the
operation is incorrect.

> (*) nan == nan is false, but, at least conceptually, a 'NotComparable'
> exception should be raised instead. That wouldn't be very useful, though.

> >> Python's way is much much cleaner.
>
> > Nope. Automatically substituting identity equality for value equality
> > is wrong. While rare, there are legitimate reasons for the former to
> > be True while the latter is False.
>
> There shouldn't be, to be fair.


Which is the whole problem. It's nice to keep erroneous conditions
out of your domain, but it's just not always possible. I don't know
how you implement NaN (which you need) without allowing for this. I
don't know how you implement SQL NULL without allowing for this.
While lots of problems can avoid this issue, I'm not sure all problems
can. Moreover, I don't know how to implement a value comparison for
many objects, so the operation should just be undefined.

I should point out that I was a little hasty in painting Python with
the same brush as C# and excluding Java. Python and Java are equally
bad: value equality defaults to identity equality but there are
distinct operations for telling them apart. People want identity
equality in Python write 'is', not '=='. People who explicitly want
value equality in Java write 'equals()'. I apologize, and blame
skipping breakfast this morning.

C# is arguably worse, since '==' on objects is defined as identity
equality unless it has been overridden. This means that that the
intent of the operation varies with no easy way to figure it out in
context, you simply have to know. C# also provides a way to test only
for identity, Object.ReferenceEquals(), but it's underused.
Ultimately this is really a problem of documentation: the language
shouldn't encourage conflation of intent in the manner it does.

> > Moreover, it means that class
> > authors must remember to write an __eq__ when appropriate and won't
> > get any sort of error when they forget to do so. That can lead to
> > bugs.
>
> I can agree on that, but that's something you can solve with a minor
> modification to the language. What I was talking about is the core
> design of Java and Python.

The only difference is I see is which comparison is performed by the
== symbol. But I don't see how nor why Python's decisions are
superior to Java. Plus, I never suggested that Python should do what
Java does, merely noted what it did since it seemed relevant to the
discussion.

Adam
--
http://mail.python.org/mailman/listinfo/python-list


askutt at gmail

Apr 26, 2012, 12:22 PM

Post #99 of 142 (2039 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 1:34pm, rusi <rustompm...@gmail.com> wrote:
> On Apr 26, 7:44pm, Adam Skutt <ask...@gmail.com> wrote:
> > On Apr 26, 10:18am, rusi <rustompm...@gmail.com> wrote:
>
> > > On Apr 26, 4:42pm, Adam Skutt <ask...@gmail.com> wrote:
>
> > > > In a mathematical sense, you're saying that given f(x) = x+2, using
> > > > f(x) is somehow more "direct" (whatever the hell that even means) than
> > > > using 'x+2'. That's just not true. We freely and openly interchange
> > > > them all the time doing mathematics. Programming is no different.
>
> > > If f(x) and x+2 are freely interchangeable then you have referential
> > > transparency, a property that only purely functional languages have.
> > > In python:
>
> > I think you misunderstood what I was trying to explain. Steven is
> > trying to claim that there's some sort of meaningful difference
> > between calling an operation/algorithm/function by some name versus
> > handing out its definition. I was merely pointing out that we
> > routinely substitute the two when it is appropriate to do so.
>
> > My apologies if you somehow took that to mean that I was implying
> > there was referential transparency here. I couldn't think of a better
> > example for what I was trying to say.
>
> > Adam
>
> And my apologies... I forgot to state my main point:
> Programmer accessible object identity is the principal impediment to
> referential transparency.
> In a functional language one can bind a name to a value -- period.
> There is nothing more essence-ial -- its platonic id -- to the name
> than that and so the whole can of worms connected with object identity
> remains sealed within the language implementation.

Yes, I agree that object identity is a major hold up, but I think side
effects are a bigger problem. It's possible in C++ to create types
that behave like the primitive types without too much difficulty,
hence making object identity unimportant. However, it's considerably
more difficult in C++ to write side-effect free code[1]. This is a
bit of an apple and orange thing, though. ;)

I often wonder what the world would be like if Python, C#, and Java
embraced value types more, and had better support for pure functions.
Unfortunately, building a language where all types behave like that is
rather difficult, as the Haskell guys have shown us ;).

Adam

[1] Or even just code that only uses side-effects the compiler
understands.
--
http://mail.python.org/mailman/listinfo/python-list


askutt at gmail

Apr 26, 2012, 12:34 PM

Post #100 of 142 (2041 views)
Permalink
Re: why () is () and [] is [] work in other way? [In reply to]

On Apr 26, 2:31pm, 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

First page Previous page 1 2 3 4 5 6 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.