[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.


On Tue, Jul 9, 2013 at 6:00 AM, <bf-python-request at blender.org> wrote:

> 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..."
>
> Today's Topics:
>
>    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
> Cc:
> 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>
> Cc:
> 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>
> Cc:
> Date: Tue, 9 Jul 2013 08:34:15 +1000
> Subject: Re: [Bf-python] proposal for updating rna/ python names of
> properties
> On Tue, Jul 9, 2013 at 4:01 AM, Dan Eicher <dan at eu.phorio.us> wrote:
> > 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.html>