[Bf-python] Addon's can no longer access context on activation.

[Campbell Barton]

On Sat, Dec 22, 2012 at 8:31 PM, dimitris chloupis <thekilon at yahoo.co.uk> wrote:
> I have to say when I first read your message for this change , I was
> surprised.
> You probably know my objection of the API braking in every release and
> generally of the
> attitude of blender as a whole of moving too fast. But I have come to accept
> that me and blender
> developers do not agree on how things should work.

in fact only one addon had to be updated (thats distributed with blender).

> Its theirs software and they can do whatever they want with it. I am just a
> visitor.

I don't see it this way, you are not just a visotor, its just very few
developers choose to become involved in our core api development which
means very few people are around to discuss topics from a position of
understanding C/python, DNA/RNA issues and help with fixing/improving
this area.

> But this change has me perplexed to say the least. If I understand correctly
> you basically took
> another big bug of blender and moved it under the carpet.

Again, disagree, even if there were no bugs relating to referencing
freed memory from python - there is the issue that tools should not
operate on data at addon load time - its that simple.

> Blender is very
> buggy piece of software
> thats not a secret , we have come to accept this.Its not the first nor the
> last.

Details, do you have examples? bug reports? - though if you mean
referencing freed memory from python, this is a real problem but hard
to avoid without significantly showing down the API (adding many
internal checks).

> But you have to realize that there are 2 kinds of people
> using blender python. People like me that have been introduced to python
> before blender, and people who
> used python for the first time with blender. Both of them expect to use an
> API thats relatively easy to use.
> Afterall this API is targeting python coders and blender users , not blender
> developers. And if people did not
> care about ease of use they will be coding blender in C anyway.

if your comments could be constructive and point at failings in the
API it could help.

> This api is not pythonic at all. Its basically one of the worse python
> libraries I have used for the same reason that
> this change has happened. Really bad design. Its powerful yet it looks like
> a C/C++ library to , and as you can imagine
> I do not have the biggest appreciation of how C/C++ coders decide to design
> (if they even bother to) their libraries.

Blender is not a python library, its an application that provides
python access to script Blender and automate tasks.
While we have tried to be pythonic where possible, in some areas I
think its better to expose functionality as it happens in C, rather
then translate into something Pythonic.
Simple example...
obj = bpy.types.Object(name="MyObj") # pythonic
obj = bpy.data.object.new(name="MyObj") # what blender currently does.

In this example attempting the pythonic style would hide that bpy.data
(blend file database) is being manipulated - unless it were possible
to have a 'bpy.types.Object' instance existing outside of a blend file
(this would give big problems, wont go into that here).

Not sure if this is the kind of thing you mean when you say blenders
api is not pythonic.

> Accessing variables on startup is the most standard practice in coding. You
> cannot go more basic than that.
> The fact that blender crashes is a blender problem not an API problem. The
> fact that I can no longer access
> variables on startup makes my coding harder. Making it harder while offering
> no advantage.

Lots of variables can be accessed, just not the blend file data.

> Not to exclude the fact that I had to compromise with storing variables
> in prop Scenes and have the same issues you describe.
>
> Even the blender excuse does not stand with my addon because I checked
> before accessing the prop in the first place.
> Blender did not crash, at all. And in any case if I did access without
> checking first then the addon would crash anyway
> if it could not find the prop. So its just common logic.

I dont follow your comments above, but just because its not crashing
doesnt mean its correct either.

> Am I missing here something else ? Is there more to this fix than meets the
> eye ?

Nope, but I think you over react - I checked on a few cases where
addons needed updating and all seemed fairly simple for the situations
I checked, just setting an operator default value on invoke rather
then when defining the property for example.

> If not I will have to 100% agree with Gert. And I made a blenderartists
> thread to see if I am the only one or not on this
> or maybe a tiny minority
>
> http://blenderartists.org/forum/showthread.php?275749-POLL-Would-u-prefer-if-the-API-was-backward-compatible-and-broke-your-addons-less&p=2265563#post2265563
>
> In any case its your decision and I respect that. I will see how I can fix
> Gyes , or remove it completely from contrib.
> ________________________________
> From: Campbell Barton <ideasman42 at gmail.com>
> To: Blender Foundation Python list <bf-python at blender.org>
> Sent: Saturday, 22 December 2012, 9:20
> Subject: Re: [Bf-python] Addon's can no longer access context on activation.
>
> Hi Gert, annoyance for the programming environment being
> limited/policed is something I can appreciate, but I think you &
> others underestimate just how flawed this kind of logic is.
>
> There is NO GUARANTEE the context when an addon loads is the same the
> next time the addon executes (draws panels, menus, runs an operator -
> etc).
> If this assumption is made, it only gives problems.
>
> Im going to enumerate the ways this may fail, these are not corner
> cases or contrived examples - users may well do any of these things
> with regular workflows.
> By the way, you could replace `scene` with active
> object/window/screen/mesh.. etc, scene is just a common case.
>
> * Blender loads -> addon loads (stores scene) -> User loads new blend
> file -> User runs addon operator -> Crash/Unpredicted behavior
>
> * Blender loads -> addon loads (stores scene) -> User changes active
> scene -> User runs addon operator -> Unpredicted behavior (why did a
> tool change the other scene?)
>
> * Blender loads -> addon loads (stores scene) -> User links in a new
> scene & switches to it -> User runs addon operator ->
> Crash/Unpredicted behavior
>
>
> To make it worse, debugging these kinds of issues isnt so easy,
> crashes wont happen every time, developers may only use simple test
> cases and not even run into problems too.
>
>
> >From what I can tell there are only disadvantages in accessing blend
> file data when loading tools.
>
> Some alternatives...
>
> * use a handler to perform actions on file load (doesn't run on
> linking scenes, but can be made to work for some cases).
> http://www.blender.org/documentation/blender_python_api_2_65_release/bpy.app.handlers.html#bpy.app.handlers.load_post
>
> * have the tool initialize settings on first execution
>
> * have a button to initialize settings (maybe a but annoying but
> consider blender already does this for cloth, fluid & smoke)
>
>
> This is probably a good time to push for addon-preferences and make it
> a target for 2.66.
>
>
> On Sat, Dec 22, 2012 at 2:34 AM, Gert De Roost <paleajed at gmail.com> wrote:
>> Good day,
>>
>> I must express my deepest regrets about this new change of "policy" for
>> script writers.  It means Ill have to equip some of my addons with an
>> unnecessary "Activate" button the user has to click to be able to start
>> using script functionality.  This way the user starts an operator in which
>> I
>> can then finally access the scene context.  For example my SelProject
>> addon
>> relies on showing a pulldown menu with all the objects in the scene.
>> Since
>> I check for changes in this through a callback, this menu will always be
>> up
>> to date, even when a new .blend is loaded.  It enables the user to set
>> parameters for the addon straight after enabling the addon, instead of
>> first
>> having to click an "Activate" button.
>> I dont like script writing "policing" like this new measure does, but
>> power
>> and possibility to do whatever we want, and leave it up to the script
>> writer
>> to police/debug his own creation.  Suppose a script accesses the scene
>> context, then enters a modal loop that does PASS_THROUGH, most certainly
>> the
>> user could now load another .blend and all the information harvested in
>> the
>> scene context could trigger these same bugs this new measure tries to
>> prevent, maybe we should stop allowing modal loops?
>
> Sure there are many other ways to cause problems, Im not so interested
> to disallow py scripters from shooting themselves in the foot at every
> moment, but loading addons is such a common case that restricting the
> context is IMHO a good thing.
>
> Also consider that we get complaints of 3rd partry addons crashing in
> our main bug-tracker from time to time, its in our interest to provide
> a system which is stable and not so error prone, not to mention a
> system that doesn't annoy users by randomly crashing.
>
>> Sorry, but Im considering to stop actively adapting my addons from now on
>> as
>> a form of protest...
>>
>> Of course I might be mistaking or not be informed well enough, Im open to
>> discussion but at the moment I am quite convinced this is not the way to
>> go...
>>
>>
>> Gert.
>>
>> _______________________________________________
>> Bf-python mailing list
>> Bf-python at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-python
>>
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>
>
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>



-- 
- Campbell