[Bf-python] nmesh.getMode() nmesh.setMode : inconsistent !

[Gert De Roost]

--- Gert De Roost <paleajed at yahoo.com> wrote:

> On Sat, 19 Feb 2005 13:23:50 -0500, Stephen Swaney
> wrote:
> > All of our bpy get/set methods *should*
> interoperate
> 
> > with .set( .get() ) as a standard idiom.
> 
> > A common api convention is for .set() methods to
> return
> > the current (before change) state so it can be
> saved
> for later restore.
> 
> It does indeed work like this for getMode() en
> setMode().  I was just misled by the API
> documentation, which only mentions setMode() using
> strings as parameters.  I believe API docs could be
> more comprehensive (like mentioning the above
> convention for .set()).  Still I am glad to see I
> was
> wrong about this consistency issue.


CORRECTION:  I have made a foolish mistake when
testing this.  Please disregard this part of my
previous post.  My apoligies if anyone got confused by
this. (Blender was registering an old version with the
old implementation in the menus, this is why
everything seemed OK).

The inconsistency does exist for NMesh.getMode() and
NMesh.setMode() (don't know about other get() set()
attributes).  getMode uses bitflags, setMode up to
five strings.  setMode(getMode()) returns:
> AttributeError: expected from none to 5 strings as
argument(s)

Also the mentioned set() api convention does not apply
to NMesh.setMode: it always returns a value of "None".

I understand you value backward-compatibility, still
this is an issue.


.gert.


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com