[Bf-python] proposal for updating rna/ python names of properties

[Bassam Kurdali]

Hi all,
This comes about after the 'squeaky wheel' discussion of python api
consumers having troubles with api breakage from version to version.

While there are some necessary and difficult to solve issues related to
changes within blender itself, there is still one source of low hanging
(possibly) fruit.

One of the *really awesome* things about the current api is the zealous
consistency in naming of rna properties according to guidelines.
Occasionally, I come across one with weird inconsistency, and I'm
reminded of the 'bad old days' of the pre-2.5 api.

However, fixing a name (even when grepping and fixing all the references
in trunk and bf_extensions) is going to break every script that uses
that name.

My proposal is (if at all possible) to 'alias' the property in the
python api after fixing, and keep the alias around for one or two
revisions, along with an info warning that is printed, stating that this
is a depreciated api and you should use X instead. This gives scripters
one or more revisions (a few months!) to find and fix the error, makes
it trivial and perhaps even automatable, and even if they miss the
window, they can load that intermediate version and see the problem.

any thoughts? is this a good idea or even a doable one? or is it already
there and I somehow missed it?

[Dan Eicher]

Hi,

Technically I think it wouldn't be too hard to have makesrna add the code
to throw a DeprecationWarning exception, just need a new flag and a bit of
code to insert into the generated function.

The main problem I see is DeprecationWarning and PendingDeprecationWarning
are 'ignored by default' so it'll probably still be a big surprise when
depreciated functions/attributes are removed unless the dev goes to all the
trouble to turn on 'warnings as errors'. From what I can tell a lot of
addons aren't known to be broken until the actual blender release that
breaks them, not a whole lot of pre-release testing going on there, so more
than likely they won't 'break' until the depreciated feature is removed
from blender for good.

Not that I'm saying this isn't a good idea (like it myself actually) just
that python's way of ignoring depreciation exceptions by default kind of
defeats the purpose.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130708/4831e22c/attachment.htm

[Campbell Barton]

Hi,
Technically I think it wouldn't be too hard to have makesrna add the code to
throw a DeprecationWarning exception, just need a new flag and a bit of code
to insert into the generated function.
The main problem I see is DeprecationWarning and PendingDeprecationWarning
are 'ignored by default' so it'll probably still be a big surprise when
depreciated functions/attributes are removed unless the dev goes to all the
trouble to turn on 'warnings as errors'. From what I can tell a lot of
addons aren't known to be broken until the actual blender release that
breaks them, not a whole lot of pre-release testing going on there, so more
than likely they won't 'break' until the depreciated feature is removed from
blender for good.
Not that I'm saying this isn't a good idea (like it myself actually) just
that python's way of ignoring depreciation exceptions by default kind of
defeats the purpose.
Dan

We can do this without much trouble, (add a flag, raise warning on access),
The annoying thing here is that we would need to store a reference to
the new property somewhere, however we could resolve that by including
it in the new property to use in the deprecated description, which
would be printed along with the warning.

This means it would also show up in the API docs and tooltip.