[Bf-python] Thought about IRC meeting and beyond

[Willian Padovani Germano]

Hi,

Toni Alatalo wrote:
> err, anything that can be evaluated as true/false should accepted where a 
> boolean is expected. those arguments should not be typechecked, just use that 
> eval func that python provides. why not just do what python does?
You're right, I was not seeing / remembering the whole pic when I 
replied. Example's like Joseph's "hello" equals True are valid points in 
favor of sane, readable code, but following Python is important. If 
users want to do silly stuff to obfuscate a little their code, it's 
their code after all.

The only real issue is making sure whatever py api call we use is 
available in the oldest Python version we're willing to support, of course.

>>Ton specifically asked us to give access via objects instead of obdata
>>right before the meeting yesterday. I'll ask him to develop his request
>>a little more to understand it throughly, so we can discuss.
> 
> i think i finally understood yesterday what he means. i guess it was that 
> operations on e.g. Meshes should be in MeshObjects, not in MeshData. i dont 
> know if it is a valid point, nor if i understood it the way he meant.

Yep, that's the idea. But as we say, seems there's more we should get 
from him to follow this discussion.

> i guess i already went away there from what Ton said, but do realize now 
> (again :) that there are no instances of Object in Blender. Every Object has 
> a type, like Mesh or Armature. so also in the API it should not be possible 
> to do Object.New() - only Mesh() Armature() etc., and then the respective 
> members should be in those classes, like armature.action and 
> mesh.data.vertices (what would a MeshOb have directly?). Blender.Object is 
> only like an abstract superclass - in a pythonic api i guess the only reason 
> to have such a type would be enabling subclassing it by py classes to 
> implement new Blender types, which the current internal architecture of 
> course prevents. so the all-new api should not have Blender.Object at all?

This suggestion is indeed a good one, like Joseph said. It would help in 
many areas and follow what Ton suggests, I guess, but then we have to 
decide about other issues.

The current ob / obdata implementation in BPy is weird according to oop, 
yes. We think it and I recall pidhash and others stating that when they 
were first learning their way around blender/bpy.

The API follows closely how it's done in Blender, ob and obdata are db 
items, _ressembling_ oop objects, but with *key differences*.

> you did ask me not to bring up issues for the all-new api before the cleanup 
> of the current is done, so am sorry having violated that request now :/

Ah no, I asked to leave the "API in Python on top of the current API in 
C" for later :), but this is something we can do for the C one. Don't 
let me scare you ;).

The pending issues I see with a more oop approach would be:

1) access to obdata that is not linked. We can create 
pseudo/bogus/proxy/temporary py objects to hold these so that scripts 
can access them. Maybe with a separate access function: 
Module.GetUnlinked() or something.

2) when we change obdata we change all objects that are linked to that 
data, not just the current one. So it must be clear to users how ob and 
obdata are related, they don't form a single independent instance of an 
specific blender ob.

I'm not dissing either the current or this proposed way, just outlining 
issues with them (problems with the current way are well known), so we 
can discuss here. My opinion is that it is ok to make this fundamental 
change in the API if it's proven better than the old approach.

And yes, this is an invitation for the oop programmers here to share 
their views :).

--
Willian