Give the `IDWALK_CB_…` enum an explicit name:
`LibraryForeachIDCallbackFlag`. This way the flags are type-safe, and
it's known where values come from. This is much preferred (at least by
me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_CB_NOP` as that has the same
value and is of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int` though.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Give the `IDWALK_…` enum an explicit name: `LibraryForeachIDFlag`. This way
the flags are type-safe, and it's known where values come from. This is
much preferred (at least by me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_NOP` as that has the same value
and is of the right type.
One invalid use of `IDWALK_CB_NOP` was detected by this change, and is
replaced by `IDWALK_NOP`.
This change might be incomplete; I gave the enum a name, and then fixed
the compiler errors.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Two commits that basically do the same thing for two `enum`s: give
them a name.
- the `IDWALK_…` enum → `LibraryForeachIDFlag`.
- the `IDWALK_CB_…` enum → `LibraryForeachIDCallbackFlag`.
This way the flags are type-safe, and it's known where values come
from. This is much preferred (at least by me) to just having `int
flags`.
Uses of `0` have been replaced with `IDWALK_NOP` and `IDWALK_CB_NOP`,
as those have the same value and are of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`. And another one in the opposite
direction.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int`
though.
No functional changes.
----------
I intend to land this PR as its two separate commits. I just put them in the same PR so the buildbot can handle them in one go, and we don't have a stack of highly relatled PRs.
In the future this could also apply to the `IDWALK_RET_…` enum. This one I left out, though, because a proper cleanup there would also have to include their ambiguity on whether they are bitflags (like the enums in this PR) or not. Their values and the code in `BKE_lib_query_foreachid_process()` implies they are bitflags, but in practice they are never or'ed together and just used as discrete values.
Pull Request: https://projects.blender.org/blender/blender/pulls/131803
Similar to 2fbf206491, but for integers (not strings). Essentially this
allows passing named integer values through UI abstractions in a clean
way.
I used 64 bit integers here, since space isn't an issue here, and it
fits common integer types (so we don't have to add APIs for multiple
integer types).
Planned to be used to fix#111463 (following commit).
Use StringRefNull for all function arguments and return types.
Not a StringRef but StringRefNull since there is still large
interaction with C api so null-termination usually necessary.
If string is expected to be not only empty but also a null then
optional is used. This change depends on #130935.
Pull Request: https://projects.blender.org/blender/blender/pulls/131204
Since [0] PyConfig_InitIsolatedConfig was used which disables
Python's signal handlers, re-enable them as they're needed for
Python's own error handling to work properly.
[0]: cd5dd6e454
These are useless now that PointerRNA has explicit default values, and
become a problem when real constructors are added to this struct. Simply
use the default empty value initialization instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/130927
Doc only mentioned 'None' separators, but 'tuple' items with an empty
identifier string are also valid separators, and allow to get 'named'
separators in the UI.
When reporting "could not create instance of {class} to call callback
function {function}", put single quotes around the name of the function.
This will make it easier to understand that that word is actually a
function name, and not some verb in the sentence.
Before:
> RuntimeError: could not create instance of
> AMP_TIMELINE_TOOLS_OT_anim_lattice to call callback function execute
After:
> RuntimeError: could not create instance of
> AMP_TIMELINE_TOOLS_OT_anim_lattice to call callback function 'execute'
Pull Request: https://projects.blender.org/blender/blender/pulls/129780
Replace plain-text type information with the type syntax used
for Python's type annotations as it's more concise, especially for
callbacks which often didn't include useful type information.
Note that this change only applies to inline doc-strings,
generated doc-strings from RNA need to be updated separately.
Details:
- Many minor corrections were made when "list" was incorrectly used
instead of "sequence".
- Some type information wasn't defined in the doc-strings and has been
added.
- Verbose type info would benefit from support for type aliases.
For C/C++ doc-strings should be located in headers,
move function comments into the headers, in some cases merging
with existing doc-strings, in other cases, moving implementation
notes into the function body.
Refactor 1dbe94c8ac restored the 'old' proper way to directly call the
python type (i.e. use the python's implementation to create objects),
instead of using the 'specialized' type creation code.
However, the handling of the ugly `rna_disallow_writes` global was only
added later to the 'workaround' part of the code, but not to the original
'canonical' one.
This commit copies the handling of `rna_disallow_writes` back into the
now active part of the code.
This solves the `is_readonly_init` unused variable build warning.
NOTE: At some point the BPY code needs a good cleanup pass, there are
way to many pieces of codes #ifdef'ed there.
For now, PointerRNA is made non-trivial by giving explicit default
values to its members.
Besides of BPY python binding code, the change is relatively trivial.
The main change (besides the creation/deletion part) is the replacement
of `memset` by zero-initialized assignment (using `{}`).
makesrna required changes are quite small too.
The big piece of this PR is the refactor of the BPY RNA code.
It essentially brings back allocation and deletion of the BPy_StructRNA,
BPy_Pointer etc. python objects into 'cannonical process', using `__new__`,
and `__init__` callbacks (and there matching CAPI functions).
Existing code was doing very low-level manipulations to create these
data, which is not really easy to understand, and AFAICT incompatible
with handling C++ data that needs to be constructed and destructed.
Unfortunately, similar change in destruction code (using `__del__` and
matching `tp_finalize` CAPI callback) is not possible, because of technical
low-level implementation details in CPython (see [1] for details).
`std::optional` pointer management is used to encapsulate PointerRNA
data. This allows to keep control on _when_ actual RNA creation is done,
and to have a safe destruction in `tp_dealloc` callbacks.
Note that a critical change in Blender's Python API will be that classes
inherinting from `bpy_struct` etc. will now have to properly call the
base class `__new__` and/or `__init__`if they define them.
Implements #122431.
[1] https://discuss.python.org/t/cpython-usage-of-tp-finalize-in-c-defined-static-types-with-no-custom-tp-dealloc/64100
While copying this used to be very cheap, this will soon be less
trivial.
Note that there are many more places where this type of cleanup will be
needed.
Remove a workaround for #23871 which manipulated the module
to prevent classes defined in the text editor from having their
name-space cleared.
This caused the "multiprocessing" module to store the "__main__" module
as "__mp_main__" for later use.
Accessing attributes from this module would then attempt to read from
with a null "mp_dict" which crashed. This happened when showing the
extensions preferences but would have occurred if "__mp_main__" was
accessed from elsewhere too.
Resolve by removing the workaround since it has not been needed
since Python 3.2.
- `_PySet_NextEntry` has been removed, use generic iterator access
which will has some additional overhead as it needs to create
an iterator to access the values.
- Add v3.13 compatibility defines to account for renaming:
_PyObject_LookupAttr -> PyObject_GetOptionalAttr
_PyLong_AsInt -> PyLong_AsInt
- Unfortunately use of Python's internal API needs to be used to
inspect op-codes in `bpy_driver.cc`.
Testing GLTF/FBX IO there isn't any significant performance impact
from these changes.
Resolves#123871.
Essentially, our current code would not properly remove (dereference)
its python objects matching various RNA data created during execution.
Some cases are fairly trivial to understand (like the lack of handling
of unregstering for our 'startup' operators and UI), other were more
subtle (like unregistered PropertyGroups who would remove/free their RNA
struct definition, without releasing first the potential matching python
object).
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/128899
The `pre` handler is called after blender internal code is done populating
the link/append context with data to be processed, and before this data
starts being linked from library files.
The `post` handler is called after blender is done linking, and
potentailly appending and/or instantiating, the requested data and all
of their dependencies.
Both handlers are called with a single argument, the link/append
context.
An new RNA sets of wrappers have been added to expose relevant info from
these internal C++ structures.
NOTE: !113658 is very similar (but tied to asset drag & drop), whereas
this PR is more general (these could probably live hand-in-hand / side-
by-side).
Implements #122357
Pull Request: https://projects.blender.org/blender/blender/pulls/128279
-----------------
Some quick py example code:
```python
import bpy
def my_handler_pre(lapp_context):
print("About to {}:\n\t".format("link" if "LINK" in lapp_context.options else "append"),
"\n\t".join("{} '{}', from libs ['{}']".format(item.id_type, item.name,
"', '".join([l.filepath for l in item.source_libraries]))
for item in lapp_context.import_items))
def my_handler_post(lapp_context):
print("{}:\n\t".format("Linked" if "LINK" in lapp_context.options else "Appended"),
"\n\t".join("{} '{}', from lib '{}'".format(item.id.id_type, item.id.name, item.source_library.filepath)
for item in lapp_context.import_items))
bpy.app.handlers.link_append_pre.append(my_handler_pre)
bpy.app.handlers.link_append_post.append(my_handler_post)
```
