[Bf-python] Re: [Bf-blender-cvs] CVS commit:
blender/source/blender/src editarmature.c editcurve.c meshtools.c
antont at kyperjokki.fi
Tue Jan 3 05:38:20 CET 2006
On Tuesday 03 January 2006 04:35, Campbell Barton wrote:
> Made respective join_* functions return 0 if the join was not mode, 1
> when it workes.
> -73 blender/source/blender/python/api2_2x/Object.c
@return: 0 is returned if the join is not successfull, otherwise 1 will be
i object this, and prefer failing operations to raise exceptions.
there are some parts in the bpy api that dont, so arguably that addition is
consistent with some existing things. but i hope inconsistent with even more
of bpy, and i think with all of normal py .. or?
is there some other reason for returning a value upon failure, like being
afraid of causing unhandled exceptions in scripts?
i suggest (again) we always adhere to the 'samurai principle' like normally in
have had painful experiences in bpy scripting when .. ah, now i see this case
is not that bad: the pain is in cases where in normal case an object to be
worked on later is expected, but e.g. a None is gotten instead. this is the
which Returns: the corresponding IpoCurve, or None.
that can hide bugs, be nasty.
perhaps this joining too?
like when you have code where join, assume it always succeeds, and then
operate on the objects later .. and get weird results, or a strange bug in
later code, and dont see that it was the join that failed and not some later
operation / your general logic / .. disclaimer: i dont know when joining can
sorry for the long messy post, must get more sleep now, but i hope the point
and thanks for all this great work, i hope you dont mind us all being such
More information about the Bf-python