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
<[email protected]> 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 <[email protected]> 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
> [email protected]
> https://lists.blender.org/mailman/listinfo/bf-python
>
>
> _______________________________________________
> Bf-python mailing list
> [email protected]
> https://lists.blender.org/mailman/listinfo/bf-python
>
> _______________________________________________
> Bf-python mailing list
> [email protected]
> https://lists.blender.org/mailman/listinfo/bf-python
--
- Campbell
_______________________________________________
Bf-python mailing list
[email protected]
https://lists.blender.org/mailman/listinfo/bf-python
