FeaturePython : return obj vs fpo

[Cyril]

I followed FeaturePython_Objects tutorial. In my opinion FeaturePython creation should return obj and not fpo in following context :

Code: Select all

 def create(obj_name):
     """
     Object creation method
     """

     obj = App.ActiveDocument.addObject('App::FeaturePython', obj_name)

     fpo = box(obj)

     return fpo

It sounds more logic to me to return obj as it is what you want to use after creation in a FreeCAD context. Seeing eg. Arch/BIM workbench obj is returned, not fpo (eg. ArchWall). I don't see any common use case where it would be preferable to return fpo.

As I am pretty new to FeaturePython creation I wanted your opinion/approval on this point before altering this wiki page.

[vocx]

...

As I am pretty new to FeaturePython creation I wanted your opinion/approval on this point before altering this wiki page.

On first instance I agree with you, it should return obj.

I had already thought this answer in my head "a lot of the programming documentation in the wiki is very old, so examples and tutorials should probably be thoroughly checked and rewritten".

However, I just noticed that this page was created earlier this year, March 2019, by Joel Graff, as "an update to Scripted objects". Joel likes to program in the best Pythonic style possible, keeping things modular and consistent, so maybe there is a reason why he wrote the examples that way. Let's ask him.

ping

[Joel_graff]

Honestly, I have no opinion.

Both results make sense to me, and I've never seen formal direction on that point. Given that each object references the other, I can't think of a reason to prefer one over the other, except that the general expectation for object creation is that a FreeCAD Document Object is returned, rather than the custom FPO. For me, in my use cases, I need the FPO reference more than I need the obj reference.

So.. whatever. I've seen both returned and have no opinion.

EDIT: Looking at this again, I'd agree returning the obj reference is probably the correct approach.

[Joel_graff]

However, I just noticed that this page was created earlier this year, March 2019, by Joel Graff, as "an update to Scripted objects". Joel likes to program in the best Pythonic style possible, keeping things modular and consistent, so maybe there is a reason why he wrote the examples that way. Let's ask him.

BTW, thanks for the compliment.

[vocx]

... I need the FPO reference more than I need the obj reference.

So.. whatever. I've seen both returned and have no opinion.
...

Where have you seen this before? Do you do this in your own workbenches?

I've seen the code that Yorik writes, Draft, Arch, BIM, and it always returns the obj, so I assume that was standard practice. I haven't particularly looked into how FEM or Path, or other workbenches do it, so I can't comment on that.

[Cyril]

For me, in my use cases, I need the FPO reference more than I need the obj reference.

I would be interested to see some uses cases where you return fpo.

In my understanding :

• If you return obj : you can still access fpo using

  Code: Select all

  obj.Proxy

• If you return fpo : you can use fpo methods but it is not a FreeCAD Document Object and have no direct access to obj unless you add a reference to it during __init__

Edit : Found it. You add reference to obj during __init__

[Joel_graff]

I would be interested to see some uses cases where you return fpo.

Right - like I say, the objects each reference each other, so it's a non-issue for me. The convention is to return the obj.

[Cyril]

I looked into modifications history and found an intriguing comment by tomkcook :

(cur | prev) 11:40, 1 July 2019‎ Tomkcook (talk | contribs)‎ . . (18,461 bytes) (-183)‎ . . (Remove references to `self.Object`- it causes serialisation problems) (undo)

Diff here
Would you mind explaining a little more ?