[Bf-python] The road to deprecation

Sybren A. Stüvel sybren at stuvel.eu
Wed Jan 7 10:30:13 CET 2015


On Tue, Jan 06, 2015 at 08:28:59PM -0700, Dan Eicher wrote:
>> 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).
> 
> 
> Isn't one of the goals of the depsgraph refactor to make these
> expensive updates more fine grained and fairly cheap? 

That's true. However, no matter how good a programmer Sergey is, not
updating at all is still cheaper.

>> Why not instead remove `frame_set` and have an explicit update
>> function?
> 
> I'd say just make scene.frame_current read-only (since it's really
> only good for that anyway)

Writing to scene.frame_current still has its uses. For example, an
importer might only perform writing/setting actions. In that case it
doesn't need an updated scene, but may need to set the current frame
number.

> and keep the current frame setting method so as to not unnecessarily
> break any scripts. 

This is exactly why I started this discussion. It would be nice to be
able to change functionality without breaking any scripts. Running a
script and checking the console for deprecation warnings is something
anyone can do, even people that do not know the script's source code.
This makes it easier to let scripts follow along with API changes.


-- 
Sybren A. Stüvel

http://stuvelfoto.nl/
http://stuvel.eu/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20150107/41e30a28/attachment.sig>


More information about the Bf-python mailing list