[Python-Dev] Matrix product
Cesare Di Mauro
cesare at pronto.it
Thu Jul 31 21:25:57 CEST 2008
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:
>>> 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).
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!'
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"...
More information about the Python-Dev