[Python-bugs-list] [ python-Feature Requests-519227 ] hook method for 'is' operator

[noreply@sourceforge.net]

Feature Requests item #519227, was opened at 2002-02-18 09:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=519227&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Parisien (mathematician)
Assigned to: Nobody/Anonymous (nobody)
Summary: hook method for 'is' operator

Initial Comment:
Being able to overload the 'is' operator would lead 
to nicer more readable code:

# constant
Open = ("OPEN",)

# dummy class for my example
class File:
	id = 0
	def __init__(self, file=None):
		if file is not None:
			self.open(file)

	# overload 'is' operator
	def __is__(self, other):
		if id(self)==id(other): # default
			return 1
		elif other==("OPEN",) and self.id!=0:
			return 1
		return 0

	def open(self, file):
		self.id = open(file).fileno

f = File("myfile.txt")
if f is Open:
	print "File is open!"
else:
	print "File is not open"

'is not' could just test __is__ and return 'not 
retval'




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-02-18 16:34

Message:
Logged In: YES 
user_id=31435

I'm afraid I agree with Neil that this would be a 
disaster.  There's code that absolutely depends on "is" 
meaning object identity.  One example (you'll find others 
if you just look for them):  _deepcopy_tuple() in the 
standard copy.py relies on it, in its second loop.  If the 
operator ever "lied" about object identity, the semantics 
of deep copies could break in amazing ways.  There's lots 
of "foundational" code in a similar boat (e.g., my own 
Cyclops.py replies on current "is" semantics all over the 
place, and that's an important example because it's not in 
the standard distribution:  we have no way to locate, let 
alone repair, all the code that would break).

If you want to pursue this, then because it's not backward 
compatible, it will require a PEP to propose the change and 
introduce a corresponding __future__ statement.

The other thing you'll get resistance on is that "is" is 
dirt cheap today, and some code relies on that too.  If it 
has to look for an object override, what's currently an 
exceptionally fast implementation:

	case PyCmp_IS:
	case PyCmp_IS_NOT:
		res = (v == w);
		if (op == (int) PyCmp_IS_NOT)
			res = !res;
		break;

will at least have to do new indirection dances too through 
the type objects (to see first whether either operand 
overrides "is").

----------------------------------------------------------------------

Comment By: Dan Parisien (mathematician)
Date: 2002-02-18 09:50

Message:
Logged In: YES 
user_id=118203

You can say the same for all the operators in python. The 
default behavior would be object identity, but:

x is y

is the same as doing

id(x)==id(y)

So the 'is' operator is actually superfluous except for 
its readability value.

Your comment seems to me like a knee jerk resistance to 
change. Now if you were to tell me that it would make 
python drastically slower or that it would be difficult to 
implement, then you would have a good point...



----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-02-18 09:30

Message:
Logged In: YES 
user_id=35752

The "is" operator has well defined semantics.  It compares
object identity.  Allowing it to be redefined would a terrible
idea, IMHO.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=519227&group_id=5470