- Remove unnecessary exception if Py_CompileStringObject fails.
- Remove unnecessary PyErr_Occurred check if Py_CompileStringObject
succeeds (based on incorrect assumption from [0]).
- Pass closeit=1 to PyRun_FileExFlags so it's responsible for closing
the file before executing code.
- Remove unnecessary temporary ReportList.
[0]: b9f6d66328
Workaround potential C-API `FILE` incompatibility by reading the
file data into memory, compiling & running it - matching existing logic
for text buffers text buffers. This replaces the in-lined stub-script
that re-opened the file from Python.
While the down-side of the stub-script was minor, it required some
non-obvious logic and had the disadvantage of requiring 2x scripts to
execute whenever a file was executed on WIN32.
Expose BLI_file_read_data_as_mem_from_handle as a public function
since it's useful to be able to read an existing FILE into memory.
Passing a directory to --python would run it as a script without errors
since the directory would read as an empty file.
Raise an error instead because this is what Python it's self does.
This would already happen on WIN32 because the stub script was
executing the file from Python.
Resolves#115090, where exceptions from the text editor called
`sys.excepthook` in v3.6 but not in v4.0.
The error was caused by PyC_ExceptionBuffer calling PyErr_Display
instead of PyErr_Print.
While technically a regression in [0], the behavior in 3.6x wasn't
working properly either since a user-defined `sys.excepthook` could
prevent PyC_ExceptionBuffer from accessing the exception text.
Resolve with the following changes:
- BPy_errors_to_report has been updated not to print errors.
Previously BPy_errors_to_report would *sometimes* print the error,
which complicated situations where the caller wanted predictable
behavior (always printing or never printing).
- `PyErr_Print()` must be used to display errors to the output,
this will call `sys.excepthook` as it used to.
It's better not to rely on side effects of BPy_errors_to_report()
for error handling.
[0]: 6a0f98aeef
Code using #PyObject_GetBuffer was combining the `PyBUF_FORMAT` and
`PyBUF_SIMPLE` flags, but the documentation specifies that
`PyBUF_FORMAT` can be |'d to any of the flags except `PyBUF_SIMPLE`
because the latter already implies format `B` (unsigned bytes).
The flags in such cases have been replaced with
`PyBUF_ND | PyBUF_FORMAT`, which has the additional requirement that the
buffer must provide it's `shape` field.
This fixes `memoryview` objects raising a `BufferError` when requested,
due to the invalid combination of flags making them be considered
invalid buffers when they would otherwise be valid.
Ref: !106697
The code from 5ac392ca4 did not work on macOS since WITH_INSTALL_PORTABLE
is not set there. This issue was hidden before, but now happens due to
the changes in #114569 to avoid using /etc/ssl.
Address issues raised by #114155.
Also fix sphinx documentation generation using incorrect identifiers
when looking up references from PyStruct types
(was looking for `bpy.app.bpy.app.driver_namespace.py`).
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
Resolve an error with SSL using a hard coded path to certificates on
Linux causing HTTPS access to fail.
request.urlopen(..) couldn't access any HTTPS URL's.
This commit makes using (most of) `BKE_report` API safe in
multi-threaded situation.
This is achieved by adding a `std::mutex` lock to the `ReportList`
struct (in a slightly convoluted way unfortunately, due to this being a
DNA struct). This lock is then used to make most operations on
`Reportlist` data thread-safe.
Note that while working on this, a few other minor issues aroze in
existing usages of Reportlist by the WM code, mainly the fact that
`wm_init_reports` and `wm_free_reports` were both useless:
- init was called in a context where there is not yet any WM, so it
was doing nothing.
- free was called on a WM that would be later freed (as part of Main
freeing), which would also call cleanup code for its `reports` data.
Both have been removed.
Further more, `wm_add_default` (which is the only place where a WM ID is
created) did not initialize properly it reports data, this has been
fixed.
This change is related to the wmJob thread-safety tasks and PRs (#112537,
!113548).
Pull Request: https://projects.blender.org/blender/blender/pulls/113561
No functional changes.
Move the following keyframing functions to the animrig folder
* `insert_keyframe_direct`
* `insert_keyframe`
* `delete_keyframe`
* `clear_keyframe`
In order to disentangle the code I had to move the following as well
* `delete_keyframe_fcurve`
* `visualkey_can_use`
* `visualkey_get_values`
In order to sort the functions I made 3 files (and their header counterparts)
* fcurve.cc
* keyframing.cc
* visualkey.cc
The following functions I made public so they won't get duplicated
* `update_autoflags_fcurve_direct`
* `ANIM_setting_get_rna_values`
There are public keyframing functions that
I left in the editors/animation/keyframing.cc file
I'd like to limit the scope of this refactor, and then
clean up the moved functions before moving even more over
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/113503
When RNA classes called into their Python methods,
exceptions would display twice once when reported and again from
PyErr_Print. This could happen when a Python defined poll method raised
an exception.
It also wasn't possible to suppress by redirecting `sys.stderr` for
example, because reporting printed directly to the stdout.
Resolve these issues by suppressing the reports output,
leaving PyErr_Print to output errors to sys.stderr.
Previously BPY_python_end wasn't called when scripts called sys.exit()
because BPY_python_end exited the Python interpreter.
Change this behavior to call BPY_python_end without exiting the Python
interpreter while freeing Blender/Python data.
While leaks in the context of sys.exit aren't especially important
it's generally preferable for sys.exit() to match Blender's code-paths
for exiting to avoid unexpected behavior.
Some of the comments for exiting were outdated & vague.
Add additional comments to clarify out SystemExit, sys.exit() & atexit
are used to handle exit requests from Python within Blender.
Non-matching calls to PyErr_Fetch/Restore cause a leak in v3.12,
so ensure calls are symmetrical or avoid where possible.
Simplify extraction of the exception buffer.
- Only overwrite the stderr (the stdio isn't used).
- Simplify pyc_exception_buffer_handle_system_exit usage.
- Remove goto's.
Also simplify calling conventions for PyC_ExceptionBuffer functions.
- They must be called when an error has occurred.
- Always return a string, never null since a null return value would
only happened in rare/unexpected cases which wasn't being checked
for by some callers, leading to potential crashes.
srna_from_self had logic to replace the exception unless there was
already an exception set. This logic isn't needed, except in some
disabled code which has been updated. If srna_from_self ran with an
exception set it would leak memory in Python 3.12.
Regression in [0] caused the function to jump to the error in the text
editor not to restore the exception, using the trace-back being iterated
over instead of the original value.
[0]: 2d2baeaf04
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
`draw_handler_add` and `draw_handler_remove` method of bpy.types.SpaceXXX
should be class method not method. However, Python API document does not show
the classmethod.
This PR fixes the Python API document of them.
Pull Request: https://projects.blender.org/blender/blender/pulls/111107
