[Python-Dev] redefining is (original) (raw)
Neil Schemenauer nas-python at python.ca
Fri Mar 19 14:47:37 EST 2004
- Previous message: [Python-Dev] redefining is
- Next message: [Python-Dev] redefining is
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Mar 19, 2004 at 12:19:11PM -0500, Andrew Koenig wrote:
Analogously, I think that the way Python defines "is" is hazardous. I do not think it is nearly as big a hazard as C++'s treatment of virtual destructors, but I still think it's a hazard. The reason is similar: Using it makes it easy to write programs that appear to work by coincidence.
Making 'is' do something other than comparing object identity is not going to help, IMHO. If you don't understand Python's object model then you are going to get into trouble anyhow.
The "raise 'quit'" example is a good one, because it will always work on an implementation that interns string literals, so no amount of testing will reveal the problem.
Not a good example. String exceptions are deprecated.
By "object equivalence", I mean mutual substitutability--which is the same as identity for mutable objects, but not for immutable ones.
So what does it mean for immutable objects?
The hazard comes about because there are objects that are equivalent but not identical, and there are contexts (such as the raise/except example above) in which it is logical to ask for object equivalence, but what you actually get is object identity.
Your raise/except example is bad. Do you have another one in which people could not just use '==' instead of 'is'?
Neil
- Previous message: [Python-Dev] redefining is
- Next message: [Python-Dev] redefining is
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]