[Bf-python] mathutil PyNumberMethods behaving badly

[Ken Hughes]

Gilbert, Joseph T. wrote:
> We don't need -vec no. It is a shorthand operator. However, I thought it
> would be nicer for the end-user.
> 
> However, now that we have 2 versions of negate(), it's debatable if we
> want to deprecate -vec because it may lead to confusion as to what it's
> doing.
> If we don't want to deprecate it, my suggestion is to give it the
> behavior of vector.negated() - i.e. return a modified copy.
> 
> As for the confusing part:
> Right now you can get the proposed behavior of vector.negated() by
> doing:
> 
> Vector(vec).negate()
> 
> however, most people will do something like this:
> 
> Vector(vec.negate())
> 
> which will modify the original vector as well.
> 
> There needs to be a way to get python-safe copies of wrapped data.

(As a preface: I already fixed the problems with unary - and ~ in 
vector.c, point.c, and matrix.c; was pretty easy.  The discussion below 
just revisits the earlier thread)

As Joseph points out, Vector(vec) will give python-safe copies of 
wrapped data.  Looking back at this discussion, I still think having two 
methods (one which modified wrapped data, one which makes a new modified 
copy) is a bad idea.  If we go that route, then what decides which 
methods aren't duplicated.  For example, do we have resize2D() and 
resize2Ded()?

I'm by no means the Python language guru, but I don't remember any of 
the basic Python data types having methods which return new copies of 
themselves; that's what copy() and related functions are for. 
Similarly, the examples of

for a in reversed(ls): ...
--vs--
ls.reverse()

and sorted(ls) -- vs-- ls.sort()

reinforce this for me.

Ken