Nick Coghlan write:
Sebastien Loisel wrote:
Dear Raymond,
Thank you for your email.
I think much of this thread is a repeat of conversations that were held for PEP 225: http://www.python.org/dev/peps/pep-0225/
That PEP is marked as deferred. Maybe it's time to bring it back to life.
This is a much better PEP than the one I had found, and would solve all of the numpy problems. The PEP is very well thought-out.
A very interesting read! I wouldn't support some of the more exotic elements tacked on to the end (particularly the replacement of the now thoroughly entrenched bitwise operators), but the basic idea of providing ~op variants of several operators seems fairly sound. I'd be somewhat inclined to add ~not, ~and and ~or to the list even though that would pretty much force the semantics to be elementwise for the ~ variants (since the standard not, and and or are always objectwise and without PEP 335 there's no way for an object to change that).
Cheers, Nick.
I agree: adding ~op will be very interesting. For example, we can easily provide case insensitive comparisons for string: if foo ~== 'Spam': print "It's spam!' equivalent to: if foo.upper() == 'SPAM: print "It's spam!' we can save both CPU time and memory to build a brand new string that will be discarded after the comparison... It will be also useful to redefine /, // and ** operators to do some common operations: 'spam, egg' / ', ' could be equivalent to iter('spam, egg'.split(', ')) # Generates an iterator 'spam, egg' // ', ' could be equivalent to 'spam, egg'.split(', ') # Generates a list and ', ' ** ('spam', 'egg') could be equivalent to ', '.join(('spam', 'egg')) but unfortunately we know that at the moment buil-in types cannot be "extended" through "monkey patching"... Cesare