[Bf-python] Getters and setters in object selection

[Bassam Kurdali]

Would it be more communicative (though more wordy) to call the function base_select() since it's not really a typical getter/setter (since the selection is on the base?
Either:
ob.base_select_get() and ob.base_select_set()

Or:
on.base_select() where all arguments are optional and calling with select=None or no argument just returns the current selection state while passing a True or False also sets it?
Cheers,
Bassam

On November 11, 2018 10:15:55 PM EST, Campbell Barton <ideasman42 at gmail.com> wrote:
>Object.select is not really correct, since the selection state isn't
>stored in the object.
>
>If we match Blender's internal state selection would look like this:
>
>----
>ob_base = view_layer.base_find(ob)
>if ob_base is not None:
>    ob_base.select = select
>----
>
>In practice this is inconvenient, although I think hiding this
>relationship entirely is also a problem.
>
>In recent 2.8 builds you can optionally pass in a view layer which
>overrides the current active view layer, eg:
>
>    ob.select_set(True, view_layer)
>
>On Tue, Nov 6, 2018 at 7:02 AM Benjamin Humpherys
><benjamin.humpherys at gmail.com> wrote:
>>
>> It makes sense that selection and visibility are not Object
>properties, but that’s an implementation detail that I don’t believe
>should to be visible in the Python API. What I’m asking is that the
>appropriate getter and setter functions be called through the standard
>python property access methods. I’m not an expert on the Python C API,
>but shouldn’t it be possible to use `PyGetSetDef` to redirect property
>access to call the new getter and setter methods, without having to
>expose this change to Python code? For example:
>https://llllllllll.github.io/c-extension-tutorial/member-vs-getset.html
>>
>> On Nov 5, 2018, at 12:15 PM, Bastien Montagne <montagne29 at wanadoo.fr>
>wrote:
>>
>> Hi Benjamin,
>>
>> TL;DR: We did that in 2.7x, it’s not possible anymore in 2.8x (not
>without **huge** changes in a large part of RNA, and adding significant
>complication to the API).
>>
>> Technical explanation:
>>
>> This decision was taken because selection status **is not an Object
>data**, not at all. It is stored in the object 'instantiation' data
>(called Base, and not exposed to Python) used to 'link' an object to a
>ViewLayer. Hence it is context-dependent info, which cannot be
>retrieved through our RNA property system.
>>
>> Ideally, there should be no access at all to that status in RNA, at
>least no setter, it should be something let to operators, or
>alternatively, we’d have to expose the whole Base concept to python.
>But that would add some noise and confusion to something already rather
>complicated (whole viewlayer/collection/object system).
>>
>> We have other similar accessors in Object API, like `visible_get()`,
>which follow the same principle (and do not have any setter).
>>
>> Note that pure-python things like @property are totally irrelevant
>here, this is using the semi-auto-generated binding to C code/data
>(through RNA), which has its own rules and limitations on top of python
>C API.
>>
>> Bastien
>>
>>
>> On 05/11/2018 18:37, Benjamin Humpherys wrote:
>>
>> I saw on the recent changes page on the wiki that the object
>selection API
>(https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Scene_and_Object_API#Object_Selection_and_Hiding)
>has changed from a simple `obj.select` property to `select_get()` and
>`select_set(’SELECT’)`. I strongly urge this decision to be
>reconsidered because it is not idiomatic Python to use getter and
>setter functions, let alone setting a boolean property with a string
>argument!
>>
>> Instead of getters and setters please consider making `select` a
>@property, or utilizing
>`PyGetSetDef`(https://docs.python.org/3/c-api/structures.html#c.PyGetSetDef)
>to hide any new getter/setter logic instead of putting it in the
>user-facing API.
>>
>>
>> _______________________________________________
>> Bf-python mailing list
>> Bf-python at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-python
>>
>>
>> _______________________________________________
>> Bf-python mailing list
>> Bf-python at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-python
>>
>> _______________________________________________
>> Bf-python mailing list
>> Bf-python at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-python
>
>
>
>-- 
>- Campbell
>_______________________________________________
>Bf-python mailing list
>Bf-python at blender.org
>https://lists.blender.org/mailman/listinfo/bf-python

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20181112/4bc509de/attachment.html>