[Bf-python] No More Renaming or Alias Vol 101, Issue 3 (Squeaky Wheel)

[Atomic Perception]

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.

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?

Having to repair scripts that used to work destroys the illusion of
progress and demoralizes developers, me for one.

Developer time should be spent making things that don't work
...work. Not making things that do work not work.

Send Bf-python mailing list submissions to
bf-python at blender.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.blender.org/mailman/listinfo/bf-python
or, via email, send a message with subject or body 'help' to
bf-python-request at blender.org
You can reach the person managing the list at
bf-python-owner at blender.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bf-python digest..."
1. proposal for updating rna/ python names of properties
(Bassam Kurdali)
2. Re: proposal for updating rna/ python names of properties
(Dan Eicher)
3. Re: proposal for updating rna/ python names of properties
(Campbell Barton)
---------- Forwarded message ----------
From: Bassam Kurdali <bassam at urchn.org>
To: bf-python at blender.org
Date: Mon, 08 Jul 2013 12:11:28 -0400
Subject: [Bf-python] proposal for updating rna/ python names of properties
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?
---------- Forwarded message ----------
From: Dan Eicher <dan at eu.phorio.us>
To: Blender Foundation Python list <bf-python at blender.org>
Date: Mon, 8 Jul 2013 11:01:13 -0700
Subject: Re: [Bf-python] proposal for updating rna/ python names of
properties
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
---------- Forwarded message ----------
From: Campbell Barton <ideasman42 at gmail.com>
To: Blender Foundation Python list <bf-python at blender.org>
Date: Tue, 9 Jul 2013 08:34:15 +1000
Subject: Re: [Bf-python] proposal for updating rna/ python names of
properties

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.
_______________________________________________
Bf-python mailing list
Bf-python at blender.org
http://lists.blender.org/mailman/listinfo/bf-python

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130709/f92061ab/attachment.htm

[Campbell Barton]

On Wed, Jul 10, 2013 at 9:32 AM, Atomic Perception

Post by Atomic Perception
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.
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?
Having to repair scripts that used to work destroys the illusion of progress
and demoralizes developers, me for one.
Developer time should be spent making things that don't work
...work. Not making things that do work not work.

Between 2.67 and 2.68 Blenders python API broke again (it sounds
dramatic, some very small things changed...)
- an redundant BMesh operator that wasn't used anywhere was removed,
its possible a script used it though.
- weight paint operators arguments and behavior changed.
- recalculate normals had an argument removed (which wasn't needed).

Note that these breakages happen because of regular blender
development, nobody went in and renamed anything.

So - we cant pretend blender is some rock solid API that would be
totally stable as long as we stopped renaming properties.
its a moving target - features are added, removed, rewritten from time
to time, scripts depending on specific behavior of areas that are
rewritten will often break.

The frequency we rename variables is so low (as in - not at all for
2.68), that if mistakes, spelling-errors, very-inconsistent-names are
changed, I think its worth doing to maintain a consistent api.

If a GSOC student manages to spell "colour" for a property name, and
somehow this slips past review, would you propose to keep this?

In blender 2.4x we had both colour/color in our API names, it was one
of the many annoying inconstancies that happened over time because of
a `dont-change-anything` policy.

[Asbjørn]

Post by Campbell Barton
Between 2.67 and 2.68 Blenders python API broke again (it sounds
dramatic, some very small things changed...)
- an redundant BMesh operator that wasn't used anywhere was removed,
its possible a script used it though.
- weight paint operators arguments and behavior changed.
- recalculate normals had an argument removed (which wasn't needed).

Unless I'm mistaken, some custom node draw function changed parameter
count, breaking LuxBlender. Then again, custom nodes is quite fresh so
breakages are kinda expected there for a while.

- Asbj?rn

[W. Nelson]

From my PoV of "ecosystem" breakage is not as much an issue as is proactive notification.? I don't see adding more code to maintain as a good ROI balance.

To quote my previous post on the matter..."The
center of gravity that I am inferring is an improved predictability
balance as in an ecological system.? The emphasis is on balance as much
as predictability. ... Something more proactive than reactive
from this vantage point improves the return on investment of time."

The devs have quite a bull to fight and I sincerely appreciate their matador heroics.? If we can manage the surprises better, devs on the sideline of the ring will spill less popcorn and enjoy the show more IMHO.

JTa




________________________________
From: Asbj?rn <lordcrc at gmail.com>
To: Blender Foundation Python list <bf-python at blender.org>
Sent: Tuesday, July 9, 2013 6:04 PM
Subject: Re: [Bf-python] No More Renaming or Alias Vol 101, Issue 3 (Squeaky Wheel)

Between 2.67 and 2.68 Blenders python API broke again (it sounds
dramatic, some very small things changed...)
- an redundant BMesh operator that wasn't used anywhere was removed,
its possible a script used it though.
- weight paint operators arguments and behavior changed.
- recalculate normals had an argument removed (which wasn't needed).

Unless I'm mistaken, some custom node draw function changed parameter
count, breaking LuxBlender. Then again, custom nodes is quite fresh so
breakages are kinda expected there for a while.

- Asbj?rn
_______________________________________________
Bf-python mailing list
Bf-python at blender.org
http://lists.blender.org/mailman/listinfo/bf-python
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130710/bfd06e22/attachment.htm

[Daniel Monteiro Basso]

On Wed, Jul 10, 2013 at 12:32 AM, Atomic Perception <

Post by Atomic Perception
Developer time should be spent making things that don't work
...work. Not making things that do work not work.

You are analyzing the proposed change from your single point-of-view, which
can be summarized as "developer who coded something and don't want to spend
more time on it". It is a perfectly valid PoV, I myself would like to spend
as little as possible maintaining my add-ons that are working just fine.
But restricting your analysis to only this PoV is somewhat egotistical.

I clearly see the value in having a consistent naming scheme, and a way to
fix things around without breaking functionality for end-users. You may not
like the possible additional work, but every active developer will surely
enjoy the benefits of this endeavor.

Besides, fixing nomenclatures is just a matter of being warned by a user
("hey, I got this warning"... everything still works, and you have months
to fix your code), and then something almost like "sed -i -e
s/oldid/newid", or whatever your editor provides you. Come on, don't you
have time for something as simple as that?

Cheers,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-python/attachments/20130710/ec30f407/attachment.htm