From the perspective of someone using the Python API to replicate interactions
with the 3D viewport, that’s VERY confusing because it is extremely un-Pythonic
and does not match the conceptual model of objects being either selected or
unselected, visible not not visible, etc. Explicit getters and setters are
normal in C++, but goes against the normal Python practice of avoiding getter
and setter functions wherever possible in favor of overriding the assignment
operator and implementing any getter/setter logic there. `Object.select_get()`
and `Object.select_set()` perform exactly the same operation and have exactly
the same result as the builtin python special methods __getattr__ and
__setattr__. I think this is a great example of “practicality beats purity”.
If I were writing a pure-python wrapper of Object, it would look something like
this:
---
class ObjectBase(bpy_struct):
@property
def select(self):
# Code for select_get here
@select.setter
def select_setter(self, value):
if isinstance(value, bool):
# Code for select_set(value) here
else:
raise TypeError(“Expected a boolean”)
class Object(bpy_struct):
def __init__(self):
self.base = ObjectBase()
@property
def select(self):
return self.base.select
@selected.setter
def selected_setter(self, value):
self.base.select = value
---
This has several advantages:
It follows the conceptual model of objects being either selected or not, just
like in the 3D viewport (very important for newcomers to Blender python
scripting)
It does not introduce a breaking change in the Python API
It follows standard Python conventions
It keeps the API clean and simple, while allowing access to the base for more
explicit control over selection state.
One tweak that would make this even better (at the cost of slight API breakage)
would be to rename “select” to “selected”. A weak adjective is a better
description of what is being altered, and would be consistent with other parts
of the API such as bpy.context.selected_objects.
If you want to make it explicit that selection is a property of the base and
not the object, you could remove the alias from Object and the context and
always require it to be on the base, as Bassam suggested, in which case
selection would be set with Object.base.selected = True.
> On Nov 12, 2018, at 7:11 AM, Bassam Kurdali <[email protected]> wrote:
>
> 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 <[email protected]
> <mailto:[email protected]>> wrote:
> Object.select <http://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 <http://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
> <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
>
> <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 <http://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
> <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
> <https://lists.blender.org/mailman/listinfo/bf-python>
>
>
>
> Bf-python mailing list
> [email protected]
> https://lists.blender.org/mailman/listinfo/bf-python
> <https://lists.blender.org/mailman/listinfo/bf-python>
>
>
> Bf-python mailing list
> [email protected]
> https://lists.blender.org/mailman/listinfo/bf-python
> <https://lists.blender.org/mailman/listinfo/bf-python>
>
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my
> brevity._______________________________________________
> Bf-python mailing list
> [email protected] <mailto:[email protected]>
> https://lists.blender.org/mailman/listinfo/bf-python
> <https://lists.blender.org/mailman/listinfo/bf-python>
_______________________________________________
Bf-python mailing list
[email protected]
https://lists.blender.org/mailman/listinfo/bf-python
