[Bf-committers] Blender 2.69 testbuild1 AHOY

[Campbell Barton]

On Sat, Sep 28, 2013 at 11:26 AM, W. Nelson <indigitalspace at yahoo.com> wrote:
> About the chain addon break report for the test build AHOY
>     and the lack of "proactive" warning or documentation
>     of change in python handling code committed to trunk--
>
>
> Very briefly, something has changed in python handling that has not been announced or is not apparent from a quick check of commits and a check of the projects page.  After about 15 minutes of checking, I see no "proactive notification" of any pending changes.
>
> This is again the issue that has been discussed previously about unannounced changes that break addons without any "proactive" warning.  I agree with Sam and his proactive attempt on this mailing list at calling attention to this type of "surprise" breakage.
>
>
> Of course a bug report needs to "reactively" be filed.  But the bigger issues is requiring "reactive" actions instead of implementing suggested simple "proactive" notifications.
>
>
> This is the whole purpose of RCs and it has been requested that people give more "feedback" on RCs or am I in error in my understanding our RC policy and feedback requests?  This is not a rhetorical question so if I am in error please enlighten me.  Maybe I am missing or overlooking something.
>
>
> As a follow-up:
>   this needs to be filed as a bug or addon bug of course
>
>   no http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.69
>       notification has been posted of this already implemented thus "surprising" change
>
>   no easy location of the change and cause in release code is found in commit logs
>
>   no notification of pending change has been posted in bf-python as a proactive warning
>
>   squeak squeak squeak squeak squeak squeak squeak ; )
>
>
> Until the bug report is filed heres the console output:
>
> Traceback (most recent call last):
> File "C:\Program Files\Blender Foundation\blender-2.68-r60361-win32\2.68\scrip
> ts\addons\object_add_chain.py", line 152, in execute
> Add_Chain()
> File "C:\Program Files\Blender Foundation\blender-2.68-r60361-win32\2.68\scrip
> ts\addons\object_add_chain.py", line 71, in Add_Chain
> abso_minor_rad=0.5,
> File "C:\Program Files\Blender Foundation\blender-2.68-r60361-win32\2.68\scrip
> ts\modules\bpy\ops.py", line 188, in __call__
> ret = op_call(self.idname_py(), None, kw)
> TypeError: Converting py args to operator properties: : keyword "use_abso" unrec
> ognized
>
> location: <unknown location>:-1
>
> location: <unknown location>:-1
>
>
>
> Thanks always for the hard work and help of core devs,
>
> Respectfully and earnestly,
>
> JTa

Operators are primarily tools for users to access, every time a tool
changes behavior or an option changes this potentially breaks scripts
that use that operator,

In the API docs its noted that operator names and args are subject to change.
http://www.blender.org/documentation/blender_python_api_2_68_release/#api-info

If we announced every change to operators behavior and args since 2.68
- it would probably be quite a long list.
However in practice its not so bad, there are many operators which
aren't used by scripts.
eg, bpy.ops.wm.sysinfo(), bpy.ops.wm.recover_auto_save(),
bpy.ops.wm.debug_menu(),
bpy.ops.mesh.dupli_extrude_cursor(rotate_source=True)

In Blender 2.4x we didn't expose tools to Python because its too hard
to maintain a stable API,
now tools are accessible but I wont guarantee they remain unchanged
between releases.