[Bf-python] Re: tp_getset conversion update

[Ken Hughes]

Willian Padovani Germano wrote:
>
> Going back to the sort of example I mentioned at the start of this 
> rewrite (strs vs. const dicts), if we have a var that can take one of a 
> group of values represented by words, doing it with a single var and a 
> constant dict seems to be the cleanest / clearest approach, don't you 
> think?
> 
> Example: object.myvar can be "strval1", "strval2", "strval3".
> 
> We use a constant dict:
> 
> Blender.Object.VALS = {STRVAL1: "strval1", STRVAL2: "strval2", STRVAL3: 
> "strval3"}
> 
> and set values like this, using the const dict facilities:
> object.myvar = VALS['STRVAL1']
> or this:
> object.myvar = VALS.STRVAL1
> 
> The same approach also works for bitfields nicely:
> 
> object.myflags = FLAGS.F1 | FLAGS.F2
> object.myflags = FLAGS.F1 | FLAGS.F2
> object.myflags &= ~FLAGS.F3
> etc.

OK, I'm just spinning my wheels now and getting nowhere.  To me, there 
is either no consensus on the list for how things should be implemented 
(and I'm reading back over months of discussion), or there is a 
consensus but I'm too stupid to see it.  Meanwhile there's three modules 
sitting in the patch tracker and another 23 waiting to submit which are 
getting outdated by CVS changes, and about 8 I haven't even looked at 
because there were pending changes or they have recently been created.

Willian's examples above are "classic" since almost every module has 
something like this. Same can be said for Toni's suggestion yesterday, 
with the exception of the "NONE" attribute; to my knowledge (and I could 
be incorrect) there isn't anything in the current API which affects two 
different Blender settings.  However, there are other modules which use 
different approaches and therein lies the problem; the API is inconsistent.

We started this project with the contention that the API is not 
consistent.  My job was to replace the getAttr()/setAttr() with 
tp_getset in each module, and as I read through all the modules note 
inconsistencies.  I also understood my responsibilities to include 
adding attributes where none existed, so that getStuff()/setStuff() 
methods could be removed at some point in the future.

I made a mistake and took it upon myself to "fix" some of the 
inconsistencies, leading to the problems Stephen raised yesterday. 
That's my fault and I'll remove such code from future submissions.

That still leaves us with an inconsistent API.  This means when I submit 
patches those who review it are going to see:
   * an exact 1-to-1 correspondence between existing attributes
   * a "best fit" attribute name, where no attributes exist but a method
     does
I'm not going to analyze the underlying data model implemented, just 
mimic it.  I want to be crystal clear on this.  Please don't question or 
reject a patch because you don't approve of how the access is 
implemented.  You're not questioning or rejecting my work, you're 
questioning or rejecting existing work in an inconsistent API.

If you know right now of something inconsistent in the API that does 
need to be changed, please document it now on the wiki page and initial 
it or send an e-mail to this list so the group can decide how to handle 
it.  I would also suggest that someone be elected to be the final 
arbiter on this (since Stephen has been reviewing most of the patches to 
this point, he is probably the natural choice, but you decide).  If no 
decision is reached, I will either leave as-is or change however the 
final arbiter directs me.

I want to see this project through to completion; however if you want 
someone else to work on it I'll be happy to turn the files I've modified 
so far over to them.  But we've got to streamline this process somehow 
so this project can get done, or just give up on it.

Ken