[Bf-python] NMesh Q

[Willian Padovani Germano]

From: <models at paposo.com>
> IC <o><o>
> The sequnence methods cause the object to be treated as a list or tuple,
> while the others are callbacks from the object's definition regarding
> getting and setting attributes. I think this should be put in some
> documentation somewhere; i.e. on how to get/set things.

This is the normal, expected behavior, for python programmers -- they'd
complain if it actually didn't work like that.  They (should) know that if
something is a seq, tuple or list, they can perform the usual ops for list,
tuple, seq.  But newbies may need an additional help and a good place for
this are the examples on the top of each module/class doc page.  It'd be
great to have improved example code in the docs, keeping in mind, of course,
that they should be small and simple whenever possible.

By the way: we need docs for your new functions, too.  Why don't you check
Object.py in api2_2x/doc and try your hand at it (no hurry, another version
of the ref doc will probably only come out with Blender 2.29).  Instructions
about epydoc are on the Blender.py one.

> One thing im confused by is in the python vert:
> NMVert_getattr callback contains:
>      else if (strcmp(name, "no") == 0)
>            return newVectorObject(mv->no, 3);
> o.k. i get that - but,
> NMVert_setattr callback contains no reference to 'co' or 'no' yet if i do
> this:
>     vertex.no[1] = 3
>     print vertex.no
> it gives me the right answer.  I don't really understand why if it's not
> defined anywhere in the vert structure............

It's like this: when you run "print vertex.no", Python looks for the
tp_getattr of the vertex (NMVert) pyobject.  This callback was defined as
NMVert_getattr, so that is the function that is called.  This you know.

But when you run "vertex.no[1] = 3", Python has to *get* .no from vertex and
only then set it's second ([1]) member.  .no is returned from get_attr as a
vector object (look at vector.c), so the method that 'sets' the value (item
assignment) is actually defined in vector.

> Also, if found a weird bug looking at the verts/normals if you do this:
(...)

This was already fixed early this week, because of a discussion at the
elysiun forums about print nmvert.co returning a list with 4 and not 3
values.  My fault, back when I started helping.

I updated the method in vector.c to check the size of the object (3 or 4
currently) before returning it's printable form, but already fixed it to
handle other values, too (not committed yet).

--
Willian, wgermano at ig.com.br