[Bf-committers] Blender Python changes
montagne29 at wanadoo.fr
Wed Oct 26 10:29:50 CEST 2016
To keeps things short: remove() behavior was previously utterly
inconsistent, a few types (Scene, at least, iirc) were also doing an
implicit unlink, while most types would not work and error if datablock
was still in use. So you had to use an horrible hack (user_clear()) to
set ID's usercount to zero before calling remove() (or ensure you
removed things in a specific order such that all users got removed
before you removed some data), also usercount was not handled correctly
in many corner cases, etc.
In a word: it could quickly turn into nightmare to clean up some data -
and it was *very* easy to make Blender crash in the process.
This has been fixed in 2.78, you now can just directly use remove()
(with do_unlink option) to get rid of some data-block, without having to
care about clearing its usages first, nor its usercount, nor anything
else. And remove() behavior has been unified, my decision to keep unlink
optional and off by default was for two reasons:
- Unlink did not happen at all in most cases (that was the main reason).
- And when it comes to handling *a lot* of data-blocks (thousands of
them), skipping unlink can be a huge time saver, it avoids several loops
over the whole Main database of data-blocks for each removed one.
So yes, this is API breakage (in some limited cases, again, iirc only
bpy.data.scenes.remove() was implicitly unlinking before) - but there
was no other solution, and this area really needed to be cleaned up, one
way or the other some default remove() behavior would have changed. By
the way, Py API is not really part of the 'we do not break anything in
2.7x series' stance, this goes mostly for the .blend file compatibility.
Py API stance has always been 'we *try* not to break anything, unless it
is really necessary'. Blender is not a library, but an end-user
application, and its API has to reflect changes to its internal
behavior, even when things exposed to end user through the UI look the same.
Now, maybe I should have rather enabled do_unlink by default, this could
have been less disruptive… But would have been much, much nicer to have
that kind of topic raised *before* we release. Because now we for sure
cannot do anything about it, which is rather frustrating for everybody.
Le 26/10/2016 à 09:18, Kai Kostack a écrit :
> Dear Blender devs,
> I'd like to provide some feedback about a recent change in BPY... OK, and share
> some frustration about it. ;)
> Just until recently you could unlink a lot of datablock types via their
> corresponding remove() methods without any problems. Now with Blender 2.78
> someone has decided to change some of these methods in a way that they throw an
> exception when there are still other users left on a default unlink attempt:
> "RuntimeError: Error: Text 'export.txt' must have zero users to be removed,
> found 1 (try with do_unlink=True parameter)"
> I thought, "Okaaay, just another parameter to add, no problem." - Why that
> would be necessary, since you could have checked for other users anyway before
> unlinking, was beyond me. - But then I realized that there are 27 datablock
> types that use an updated remove() method while others remained unchanged. I
> have like 100 scripts for Blender 2.76 at my disposal and ca. 30 of them have
> at least one ".remove(" in the code. "Wow, that's a lot of scripts that might
> have been broken by now", I thought. Note that you can't easily go over them
> and add the parameter because not all remove methods of Blender would accept it
> (not to mention general Python list removes). So I had to look up each and
> every line with 'remove' in the API if they were changed or not. That was fun.
> While the scripts will (probably) all work by now again, I got first complains
> that some of my Add-ons wouldn't work with 2.77 builds anymore. Great. To make
> a long story short, I have decided to implement BOTH ways of calling remove via
> try & except now, just to make sure the code will work in both versions, 2.77
> and 2.78.
> I remember a statement along the lines that breaking things will be postponed
> until 2.8 and that 2.7x should be kept in a working state. - This is not a call
> to change it back, I just want to give you a glimpse of what seemingly appears
> to be a clever and small change in design can mean to users, and that they
> eventually have to include more and more workarounds and hacks just to
> circumvent your 'clever design' to make things just work. Sometimes less is
> With respect,
> -- Kai
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers