[Bf-python] mathutil PyNumberMethods behaving badly

[Campbell Barton]

having Mathutils.Invert() seems bad to me. 1, because its undifined,  
invert what? 2, because its out of line with matrix.invert() and its 
confusing to have very similar functionality accessed in 2 different ways..

Feel free to disagree ;)

been thinking about this...
what about add a .copy() to all Mathutils data and remove all the 'ed' 
functions, as well as making the operations that modify the data in 
place return a copy of them selves like they do in 2.42.




Gilbert, Joseph T. wrote:
> Interesting idea.
> Mathtuils.Invert() vs. vector.invert()
> Where Mathtutils.Invert() returns a safe copy....
>
> -----Original Message-----
> From: bf-python-bounces at projects.blender.org
> [mailto:bf-python-bounces at projects.blender.org] On Behalf Of Ken Hughes
> Sent: Thursday, August 17, 2006 2:33 PM
> To: Blender Foundation Python list
> Subject: Re: [Bf-python] mathutil PyNumberMethods behaving badly
>
>
>
> 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
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>
>   


-- 
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