[Bf-python] The road to deprecation

Bassam Kurdali bassam at urchn.org
Sat Dec 20 19:16:19 CET 2014


+1 for a formal way to deprecate api - this method would be good.

About Scene.frame_current - It's less useful than set_frame() because
the latter actually updates the scene to the new frame, but maybe there
are use cases where you just want to write to the property without (yet)
forcing an update? (though I'm not sure when or why you would want
that.)

I think getting a warning when the api writes to frame_current could be
a nice thing even if not deprecated, because most people actually want
to update the frame, not just write the property.

On Sat, 2014-12-20 at 12:18 +0100, Sybren A. Stüvel wrote:
> Hi folks,
> 
> Is there any way, at the moment, to deprecate parts of the Python API? I've 
> always been a fan of the following:
> 
> 1. Method calls, property access etc. can be annotated as "deprecated".
> 2. In version N, we start displaying a warning when deprecated functionality
>    is used. This warning also mentions version N+1 as the version in which
>    it will stop working.
> 3. In version N+1, turn the warning into an error.
> 4. In version N+2, remove the functionality altogether.
> 
> How N, N+1 and N+2 map to Blender versions is another discussion. I'm just 
> wondering whether such a system exists in Blender, and if not, if people would 
> find it interesting.
> 
> The "root cause" for this, is the Scene.frame_current property. It's currently 
> writable, but its documentation tells you to call Scene.set_frame() instead. 
> This made me think about deprecating writing to Scene.frame_current, hence 
> this email.
> 
> Best,
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python





More information about the Bf-python mailing list