[Bf-python] Consistency issue

Stephen Swaney sswaney at swbell.net
Thu Oct 2 00:06:04 CEST 2003


Michel Selten wrote:
> 
> (...)
> 1 - Keep it working, don't bother consistency.
>     This implies not using the valtuple variable. But, reading on,
>     it would also imply that the Python modules on the outside won't
>     become consistent as well.

One way to do this is to use separate functions for setLocation
and obj.loc=.  The loc= func *has* to take single object which means
a tuple.  The setLocation method can use anything for its params.

> 2 - Break API compatibility in the setLocation() function. The old
>     call to it in a script is:
>     obj.setLocation (0.0, 0.0, 0.0)
>     The new call would be:
>     obj.setLocation ((0.0, 0.0, 0.0))
>     This option would make the setLocation function work the same
>     as in the Curve module for example.
> 3 - Update the setLocation() function to both accept a tuple and a
>     list of values. This would imply that both the following calls
>     are valid in a script:
>     obj.setLocation (0.0, 0.0, 0.0)
>     obj.setLocation ((0.0, 0.0, 0.0))
> 
> My personal preference would go to option 3. But, there's a problem that
> I'm unable to solve. Quite possibly because I'm unaware of the existance
> of a Python function.
> Here's what the implementation of the setLocation() function would look
> like (partly):
> 
> /* parse ((0.0, 0.0, 0.0)) */
> if (PyArg_ParseTuple (args, "O", &list_args))
> { ... }
> /* parse (0.0, 0.0, 0.0) */
> else if (PyArg_ParseTuple (args, "fff", &loc1, &loc2, &loc3))
> { ... }
> else return error
> 
> The problem is that if the first if statment fails, the content of the
> variable args is not available anymore. So I need to have a copy of the
> variable somewhere. What's the Python call for that?

I *think* you would have to do this by hand:
  Get the length of the incoming tuple.
  Create a new tuple of the correct size.
  Fill in all the slots in the new tuple

I will look into this.

> 
> The 3rd option would make it possible to generally shift all slightly
> faulty methods to the correct implementation. We can warn the user about
> the deprecation of the old method in a few releases and support the new
> method only after that.

One way to deal with this is to leave setLocation( float,float, float)
and create new setLoc( tuple_of_3_floats ).  Then the setattr call
could go thru setLoc().

> 
> What do you think?
> 

The Object method getLocation returns a tuple of floats.
( the PyBuild_Value call uses "fff", but this creates a tuple
if there is more than one arg in the format string )

According to the docstring in the code for Object.setLocation, 
it takes a vector triple.  I believe this is correct since
it allows us stuff like 

	obj1.setLocation( obj2.getLocation() )

without jumping thru syntactic hoops.

A second argument for passing in a tuple is that if you are doing
3D math you tend to have vector-like objects lying around.


More information about the Bf-python mailing list