[Bf-python] shared properties?

[Willian Padovani Germano]

On Sun, 2003-06-23 at 08:09, Yann Vernier wrote:
> When testing exppython I ran into the issue that the new Object
> implementation didn't have the name attribute.

It will have, naturally, to follow the other modules.  The duplication
you complain about also annoyed me while I was implementing these
things, but one objective was more important: clean, readable code that
others could look at, learn from and extend / improve.

We're already at a point where reasons that were important when Michel
started the exppython project have become dated, because exppython is
easy to read and learn from.  The older code was a terrible mess for
newcomers (we all) to follow and understand, specially when this also
involved knowing the Python/C API and Blender internals.

> Right now some
> types don't implement __members__ so only methods show up. 

__members__ is necessary for the new types if they want to follow the
overall design.  But remember that things are not finished yet, we're
still working.  And some modules were ported from the old implementation
(BGL, Draw and NMesh), to speed things up, so they don't follow the way
we've been working.  The first objective is to reproduce the current API
so that we can get rid of frozen modules and the remains of previous
implementations.  In the meantime, new developers brought new modules. 
It would be good to have them complete and following the design, but not
crucial for a first release.

> I'm not sure how much of the old API has [sg]etName() functions that
> work. If I'm not mistaken they failed to work on meshes and objects
> (even the argument for New() was uniplemented). Could someone explain to
> me why the method interface is necessary?

Some of them were already available in the 2.25 API and so needed to be
kept for compatibility (though the 2.25 doc and actual code didn't
"agree" in some points).  When I began to help, it was natural for me to
add the missing ones, since that was the safer -- also recommended by
the 2.25 doc -- way to access the variables (they checked the values). 
But then I made the setattr function call the set* methods and both ways
became safe.

We can take away most methods and only use direct access through member
vars, leaving only the ones that were already in the API, but this is
against a uniform interface.  And since we have the functions anyway 

-- you mention that it means two extra functions for each attr, but
consider that setAttr would be too bloated with all the tests/cases done
inside it (take Lamp and Material, for example) --

there's no reason not to expose them all to Python programmers.  They
choose what they prefer to use.

Funnily the opposite of what you suggest has also been suggested: not to
implement the get/setAttr way.  But it's better to have it because it's
the Pythonish way of doing these things.

The main thing is this: right now, we're in a hurry to pack what we
have, test and document it and give exppython to the official Blender
executables.  People have been waiting way too long for results, bug
fixes and more functionality.  Code reorganization can come later,
specially separating exppython code from Blender internals.  Changes to
the API are a delicate issue, when users are already so tired of them.  

We can later clean the API, get rid of some things, standardize names
properly, etc., but this only with feedback from script writers.  It may
happen that they prefer not to change it once again, since Blender 3.0
will eventually have a new one anyway -- I know it's far from us, but my
months are passing so fast that I can't help thinking about it.

--
Willian, wgermano at ig.com.br