[Bf-python] mathutil PyNumberMethods behaving badly

[Campbell Barton]

Ken Hughes wrote:
>
>
> 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

Not sure which the best way to go with this is... I see why your are not 
keen on having 'ed' functions, but practically you  theres a few 
arguments for it as well.

saying Vector(vec) is a way to copy is fine. but at any time when you 
havnt imported Vector from Mathutils it can take up too much room.

Here are some examples of Mathutils  where Mathutils.Matrix is too 
lengthy... (from bundeled scripts)


    bonerest[bonename]=Blender.Mathutils.Matrix(b.matrix).resize4x4()
    emprest[empty.getName()]=Blender.Mathutils.Matrix(empty.getMatrix('localspace')).resize4x4()
    bonerest[bonename]=Blender.Mathutils.Matrix(b.matrix).resize4x4()

    emprest[rootEmpty.getName()]=Blender.Mathutils.Matrix(rootEmpty.getMatrix('localspace')).resize4x4()

    invemprestmat =
    Blender.Mathutils.Matrix(emprest[empty.getName()].rotationPart()).resize4x4()

    Init_Mat=Blender.Mathutils.Matrix(child.getMatrix('worldspace'))
    #must be done like it (it isn't a matrix otherwise)
    Init_Mat.invert()



with the 'ed' functions theres a bit of redundancy, but that that much, 
theres only a handfull of functions anyway,
nothing compared to the getFoo/setFoo/foo problems of other modules 
*(Not that we want to replicate that at all)

Having Matrix(mtx) to copy the matrix is neat but dosent read well, 
because  its on the other end of the line...

mtx= ob.matrixLocal.copy().invert()
emprest[rootEmpty.getName()]=rootEmpty.getMatrix('localspace').copy().resize4x4()

(reads nicer then )
mtx= Matrux(ob.matrixLocal).invert()
emprest[rootEmpty.getName()]=Blender.Mathutils.Matrix(rootEmpty.getMatrix('localspace')).resize4x4()


Also, unless you know that it copy's from reading the docs, its non obvious.

Id be up for removing the 'ed's in favor of a .copy() function.

- Cam

-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241