<div dir="ltr"><div><div>I am one of those squeaky wheels. Please don't rename anything and please don't spend valuable developer time implementing an alias system. What does it matter if I have to type 'birthtime' or birth_time' to reference my value? If it ain't broke don't fix it. Dang...nuf said.<br>
<br></div>Now that scripts are up and running I can't believe you want to keep renaming things. Or better yet, let's rename things and delay the braking of those renames for how many releases?<br><br></div>Having to repair scripts that used to work destroys the illusion of progress and demoralizes developers, me for one.<br>
<div class="gmail_extra"><br></div><div class="gmail_extra">Developer time should be spent making things that don't work<br></div><div class="gmail_extra">...work. Not making things that do work not work.<br><br><br></div>
<div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 9, 2013 at 6:00 AM, <span dir="ltr"><<a href="mailto:bf-python-request@blender.org" target="_blank">bf-python-request@blender.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Bf-python mailing list submissions to<br>
<a href="mailto:bf-python@blender.org">bf-python@blender.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.blender.org/mailman/listinfo/bf-python" target="_blank">http://lists.blender.org/mailman/listinfo/bf-python</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:bf-python-request@blender.org">bf-python-request@blender.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:bf-python-owner@blender.org">bf-python-owner@blender.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Bf-python digest..."<br>
<br>Today's Topics:<br>
<br>
1. proposal for updating rna/ python names of properties<br>
(Bassam Kurdali)<br>
2. Re: proposal for updating rna/ python names of properties<br>
(Dan Eicher)<br>
3. Re: proposal for updating rna/ python names of properties<br>
(Campbell Barton)<br>
<br><br>---------- Forwarded message ----------<br>From: Bassam Kurdali <<a href="mailto:bassam@urchn.org">bassam@urchn.org</a>><br>To: <a href="mailto:bf-python@blender.org">bf-python@blender.org</a><br>Cc: <br>Date: Mon, 08 Jul 2013 12:11:28 -0400<br>
Subject: [Bf-python] proposal for updating rna/ python names of properties<br>Hi all,<br>
This comes about after the 'squeaky wheel' discussion of python api<br>
consumers having troubles with api breakage from version to version.<br>
<br>
While there are some necessary and difficult to solve issues related to<br>
changes within blender itself, there is still one source of low hanging<br>
(possibly) fruit.<br>
<br>
One of the *really awesome* things about the current api is the zealous<br>
consistency in naming of rna properties according to guidelines.<br>
Occasionally, I come across one with weird inconsistency, and I'm<br>
reminded of the 'bad old days' of the pre-2.5 api.<br>
<br>
However, fixing a name (even when grepping and fixing all the references<br>
in trunk and bf_extensions) is going to break every script that uses<br>
that name.<br>
<br>
My proposal is (if at all possible) to 'alias' the property in the<br>
python api after fixing, and keep the alias around for one or two<br>
revisions, along with an info warning that is printed, stating that this<br>
is a depreciated api and you should use X instead. This gives scripters<br>
one or more revisions (a few months!) to find and fix the error, makes<br>
it trivial and perhaps even automatable, and even if they miss the<br>
window, they can load that intermediate version and see the problem.<br>
<br>
any thoughts? is this a good idea or even a doable one? or is it already<br>
there and I somehow missed it?<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Dan Eicher <<a href="mailto:dan@eu.phorio.us">dan@eu.phorio.us</a>><br>To: Blender Foundation Python list <<a href="mailto:bf-python@blender.org">bf-python@blender.org</a>><br>
Cc: <br>Date: Mon, 8 Jul 2013 11:01:13 -0700<br>Subject: Re: [Bf-python] proposal for updating rna/ python names of properties<br><div dir="ltr">Hi,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div>
<div>
Dan</div></div>
<br><br>---------- Forwarded message ----------<br>From: Campbell Barton <<a href="mailto:ideasman42@gmail.com">ideasman42@gmail.com</a>><br>To: Blender Foundation Python list <<a href="mailto:bf-python@blender.org">bf-python@blender.org</a>><br>
Cc: <br>Date: Tue, 9 Jul 2013 08:34:15 +1000<br>Subject: Re: [Bf-python] proposal for updating rna/ python names of properties<br>On Tue, Jul 9, 2013 at 4:01 AM, Dan Eicher <<a href="mailto:dan@eu.phorio.us">dan@eu.phorio.us</a>> wrote:<br>
> Hi,<br>
><br>
> Technically I think it wouldn't be too hard to have makesrna add the code to<br>
> throw a DeprecationWarning exception, just need a new flag and a bit of code<br>
> to insert into the generated function.<br>
><br>
> The main problem I see is DeprecationWarning and PendingDeprecationWarning<br>
> are 'ignored by default' so it'll probably still be a big surprise when<br>
> depreciated functions/attributes are removed unless the dev goes to all the<br>
> trouble to turn on 'warnings as errors'. From what I can tell a lot of<br>
> addons aren't known to be broken until the actual blender release that<br>
> breaks them, not a whole lot of pre-release testing going on there, so more<br>
> than likely they won't 'break' until the depreciated feature is removed from<br>
> blender for good.<br>
><br>
> Not that I'm saying this isn't a good idea (like it myself actually) just<br>
> that python's way of ignoring depreciation exceptions by default kind of<br>
> defeats the purpose.<br>
><br>
> Dan<br>
<br>
We can do this without much trouble, (add a flag, raise warning on access),<br>
The annoying thing here is that we would need to store a reference to<br>
the new property somewhere, however we could resolve that by including<br>
it in the new property to use in the deprecated description, which<br>
would be printed along with the warning.<br>
<br>
This means it would also show up in the API docs and tooltip.<br>
<br>
<br>_______________________________________________<br>
Bf-python mailing list<br>
<a href="mailto:Bf-python@blender.org">Bf-python@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-python" target="_blank">http://lists.blender.org/mailman/listinfo/bf-python</a><br>
<br></blockquote></div><br></div></div>