[Bf-python] mathutil PyNumberMethods behaving badly

Gilbert, Joseph T. jgilbert at tigr.ORG
Thu Jul 20 22:42:59 CEST 2006


This was something we discussed a few months ago.
The proposal was to have a 2 methods. One which returns a self-modified
reference and another that returns a modified-copy.

Example:
ref_to_orig_vector = vector.negate()
new_mod_vector = vector.negated()

The -vec are shortcuts in pymath. They should be bound to either of the
2 above methods. It would make sense to have them be bound to the
version that returns a new_modified_vector for safety.

To keep the current API "negate" would continue to do what it does now.
We would need to add "negated", etc. for all the self-modifying methods
of all the py math objects that require them. 


-----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, July 20, 2006 2:29 PM
To: Blender Foundation Python list
Subject: [Bf-python] mathutil PyNumberMethods behaving badly

Cam discovered a problem in the mathutils with expressions like this:

me = Mesh.Get('Cube')
x = -me.verts[0].co
print x
print me.verts[0].co

You get this:

[-0.565980, -1.386673, 0.000000](vector)
[-0.565980, -1.386673, 0.000000](vector)

Joseph put in code which modifies the original object, since script 
users wanted to concatenate operations, but I don't think we really want

to this with math operations (i.e., PyNumberMethods).

Seems to me we need two type of operations in mathutils: one modify the 
original data and return it and ones that don't (now on three: 1, 2, 3, 
"Duh").  Obviously the math operations shouldn't do this, but looks like

we need to "un-deprecate" some of the original methods like
vector.negate()

Ken
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python



More information about the Bf-python mailing list