[Bf-python] The road to deprecation

[Campbell Barton]

This thread covers a few issues, but I think it misses a more general problem.

For scripting you may want to separate assignment from its typical
side-effects (that you'd expect as a user).

Often its related to performance - so you can batch edits and postpone
re-evaluating data until they're all done.

But you may wan't to keep the old state in some cases too.

As a user, if you set the filepath of an image (for example), you
normally want it to load that image.

But when scripting, you may want to set an image path so it will
un-pack to that location... or so saving will write a newly-generated
image to that path. (This is a problem, and why we have 2x attributes
`filepath, filepath_raw` for images, which isn't very good design
either).

For `frame_current` the examples where you might take advantage of the
current behavior are less obvious.

Setting keyframes for the current object's state at 2 or more
different points in time. Basically any operation where you want to
change the frame and write-state, rather than reading it.

There are so many cases where you _might_ want an update that I think
its better to be explicit here.

For example, if you set a vertex location you don't get the result in
Python (updated bounding box etc) until you run `scene.update()`.
But it doesn't make sense to add a vertex.set_co() method just to get
an instant update. (wouldn't have to be added for every other data
type... uv's etc).


Why not instead remove `frame_set` and have an explicit update function?

::
   scene.frame_current = 123
   scene.frame_update()

Then we keep the rule of thumb that expensive global re-evaluation is
done explicitly.


On Tue, Dec 23, 2014 at 3:38 AM, Daniel Monteiro Basso
<danielmbasso at gmail.com> wrote:
> On Mon, Dec 22, 2014 at 3:56 PM, Sybren A. Stüvel <sybren at stuvel.eu> wrote:
>>
>> An animation importer could have a use for writing to frame_current.
>> Since it only imports data, it may be independent of the already
>> existing data, hence a full scene update is not needed.
>
>
> Scene.set_frame(x, update=False)
>
>>
>> Personally, I think this would be a good enough use case to not deprecate
>> writing to
>> frame_current.
>
>
> From the Zen of Python (`import this`):
> - Explicit is better than implicit.
> - Special cases aren't special enough to break the rules.
> - In the face of ambiguity, refuse the temptation to guess.
> - There should be one-- and preferably only one --obvious way to do it.
>
> So I wholeheartedly agree with deprecating frame_current and incorporating
> its behavior into set_frame.
>
> Cheers,
> Daniel
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>



-- 
- Campbell