[Binding/Sofa.Core] Call init() by default when creating a python object #173
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The default behavior should be the most common use case while more
rare scenario should be accessible through explicit call.
Currently the default case is:
m = r.addObject("MechanicalObject", position=[1,2,3])
m.init()
l.rest_position() ## Rest position is created from position at init
This is a bit weird as one may expect that once "created" in python the object is
immediately accessible in an inited state (not doing so imply user to call init() at every lines).
After the PR the default case become:
m = r.addObject("MechanicalObject", position=[1,2,3])
l.rest_position()
But for rare use case where it makes sense the no init behavior can be done like that:
m = r.addObject("MechanicalObject", position=[1,2,3], doNoInit=True)
l.rest_position() # Rest position is "uninited"
m.init() # You can control when you init the object
l.rest_position() #
Unit tests are provided to validate the behavior.
damienmarchal
changed the title
hugtalbot
changed the title
To control if users want to activate news features in the binding.
…tures.
The mechanisme is composed of three parts:
- SofaPython3::Config (the c++ part)
- SofaPython3::Binding::Config (the python binding)
Activating an existing futurefeature:
-------------------------------------
```python
import SofaPython3.__futurefeatures__
SofaPython3.__futurefeatures__.object_auto_init = True # To activate the auto init feature.
```
Adding a new futurefeature:
---------------------------
In binding/Sofa/package/__futurefeatures__.py, add you feature at the end of the
FeatureSet::__init__ constructor.
In your c++ code you can test if the feature is activated by doing
```c++
#include <SofaPython3/Config/futurefeatures.h>
if( sofapython3::config::futurefeatures::get("myFeature") )
....
```
In your python code you can test if the feature is activated by doing
```python
import Sofa.__futurefeatures__
if Sofa.__futurefeatures__.myFeature:
print("The feature is activated")
```
Signed-off-by: Damien Marchal <[email protected]>
At each scene load the loaded python modules should be cleaned so they can be reloaded. Signed-off-by: Damien Marchal <[email protected]>
…__enable_future__
To control if users want to activate news features in the binding.
…tures.
The mechanisme is composed of three parts:
- SofaPython3::Config (the c++ part)
- SofaPython3::Binding::Config (the python binding)
Activating an existing futurefeature:
-------------------------------------
```python
import SofaPython3.__futurefeatures__
SofaPython3.__futurefeatures__.object_auto_init = True # To activate the auto init feature.
```
Adding a new futurefeature:
---------------------------
In binding/Sofa/package/__futurefeatures__.py, add you feature at the end of the
FeatureSet::__init__ constructor.
In your c++ code you can test if the feature is activated by doing
```c++
if( sofapython3::config::futurefeatures::get("myFeature") )
....
```
In your python code you can test if the feature is activated by doing
```python
import Sofa.__futurefeatures__
if Sofa.__futurefeatures__.myFeature:
print("The feature is activated")
```
Signed-off-by: Damien Marchal <[email protected]>
…add-no-init-behavior-at-default # Conflicts: # bindings/Sofa/package/future.py
…havior-at-default
…add-no-init-behavior-at-default
…ture # Conflicts: # bindings/Sofa/tests/PythonModule_Sofa_test.cpp
…time.future To make that consistant with the "lifetime" namespace we already have in Sofa.
…havior-at-default # Conflicts: # bindings/Sofa/tests/PythonModule_Sofa_test.cpp
…add-no-init-behavior-at-default # Conflicts: # bindings/Sofa/package/lifetime.py
|
@AlbanOdot @jnbrunet @RobinEnjalbert what do you think of this auto-init feature? |
|
@hugtalbot so as there was no answer it will be time to plan updating and merging ;) |
|
Related to the need for init: |
|
Reviews taken into account. However, this scene often crashes with such error: double free or corruption (out)
########## SIG 6 - SIGABRT: usually caused by an abort() or assert() ##########I am suspecting the engine TextureInterpolation |
|
Thanks for the feedback, can you provide a scene that crash (or elaborate a bit more). As the risk of incompatibility with some component we don't have time to fix is high this is why this PR rely on the use of #184 with __feature__("autoinit"):
blabblah |
|
the scene here crashes @damienmarchal quite randomly. What I wrote regarding the init should work fine, shouldn't it? |
|
@hugtalbot Sorry I'm lost, what do you mean by "here" ? |
|
sorry I initially posted in the wrong PR (I was targeting #204) ! sorry for perturbating this one! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The default behavior should be the most common use case while more
rare scenario should be accessible but with explicit call api (opt-in vs opt-out strategy).
Currently the default case is:
This is a bit weird as one may expect that once "created" in python the object is
immediately accessible in an inited state (not doing so imply user to call init() at every lines).
After the PR the default case become:
But for rare use case where it makes sense the no init behavior can still be done explicitly:
Unit tests are provided to validate the behavior.
The PR use the Sofa.future module to let users to enable/disable the behavior.
By default, the SofaPython behavior is preserved (so no auto-init)
If you want to test you just need to do
This PR depends on #184