[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