[Bf-committers] Python API breakage - squeaking wheels

[Domino Marama]

On 05/28/2013 02:31 PM, Campbell Barton wrote:
> >From your mail it looks like all changes you note were from bmesh
> upgrade (except build_revision)
>
> On Tue, May 28, 2013 at 9:36 PM, Domino Marama
> <domino at dominodesigns.info> wrote:
>> For my scripts the changes to UV handling caused the most problems..
>> Supporting multiple Blender versions from same script version results in
>> code like this:
>>
>>         u_points = []
>>         v_points = []
>>         mesh = obj.data
>>
>>         if svn <= 44243:
>>             for f in mesh.uv_textures[uv_name].data:
>>                 for u, v in f.uv:
>>                     u_points.append(u)
>>                     v_points.append(v)
>>         else:
>>             if svn > 45996:
>>                 uv_loops = mesh.uv_layers[uv_name].data
>>             else:
>>                 loopindex = mesh.uv_textures.keys().index(uv_name)
>>                 uv_loops = mesh.uv_layers[loopindex].data
>>             u_points = [v.uv.x for v in uv_loops]
>>             v_points = [v.uv.y for v in uv_loops]
>>
>> And other changes mean I have to do this to get the svn version :)
>>
>>     try:
>>         svn = bpy.app.build_revision.decode().split(':')[-1].rstrip('M')
>>     except:
>>         svn = bpy.app.build_revision.split(':')[-1].rstrip('M')
>>     svn = int(svn)
> This isn't totally reliable, some builds dont include buildinfo, Id
> suggest using blender version rather then checking revisions.
> Also moving to git - revisions will work differently too.
Yeah I just posted that because of the irony in my routine for handling
API changes being affected by them. I'm sure you see the additional
irony in pointing out that it is going to break again in the future :)

In the full code the svn = int(svn) line is in a try: except with a
fallback of estimating a svn number from the Blender version. I had to
do it this way as the Blender version isn't updated until release so
when API breakages occur I need to be able to target specific commits to
test against current builds
> It does but also confirms that BMesh was main offender (not sure you
> were aware of this regarding UVs?).
>
Yeah the majority of the the current switches in my code are bmesh
related. I couldn't do a full switch to bmesh without losing backward
compatibility, so it's mostly old API with just the UV handling from
bmesh on newer versions. Now there's enough old versions with bmesh I
can plan the full migration of the code to the new APIs.

Prior to that the last big script shakeup was the switch to python3.

I really posted as an example of a different way that script authors may
be working. Assuming a new Blender release with API changes means that
script authors will do new versions of their scripts makes work for
people who may not have scheduled for it. Having a few releases where
depreciated functions give warnings lets people schedule these things in
rather than having to make it their main priority. For those of us who
support older versions on same scripts, it also makes life a little
easier as we could fall into synch with the depreciation cycle rather
than having to work around things to keep compatibility.