Thank you for the explanation. It makes more sense to me now and I see the advantages of the changes. However, I still think that the average use case would be unlinking without the hassle to handle all references manually for a 'simple' script. I would consider writing simple scripts even a general user requirement and not so much something exclusively reserved for die-hard add-on development. By the way, I realized the ramifications of the changes just in the last two days, otherwise I would have voiced up earlier. -- Kai
> Gesendet: Mittwoch, 26. Oktober 2016 um 10:29 Uhr > Von: "Bastien Montagne" <[email protected]> > An: [email protected] > Betreff: Re: [Bf-committers] Blender Python changes > 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. > > Regards, > Bastien > > 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 >> more. >> >> With respect, >> >> -- Kai >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> https://lists.blender.org/mailman/listinfo/bf-committers >> > > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers[https://lists.blender.o > rg/mailman/listinfo/bf-committers] _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
