Use Python 3.8's API for setting the initial configuration.
This replaces a mix of our logic and direct calls to the Python API
and has no user visible changes.
Using the Python API makes the logic easier to follow and provides
utilities such as `PyConfig_SetBytesArgv`
that wasn't available in previous releases.
Note that this uses Python's utf8/wchar_t conversions,
which used to cause problems (see T31506).
Since `Py_UTF8Mode` was set, the systems locale isn't used for decoding,
allowing us to use Python's utility functions that call
`Py_DecodeLocale` internally.
Ref D10382
System encoding issues have been a paint-point for us with Python 3,
since Blender always uses UTF-8 which might not be the case for the OS.
While the Py_SetStandardStreamEncoding was already set to utf-8,
the file-system could still have an incompatible encoding.
See PEP-540 for details.
BPY_context_dict_clear_members_array used PyDict_DelItemString
which raised & cleared the exception when the key didn't exist.
Even though setting/clearing the exception is supported,
it's worth avoiding where possible as it adds some overhead as well as
overwriting the previous error which can free PyObject's which are
unrelated to the code being executed.
Possible fix for T82552, crashing on Windows when setting the exception.
This was added when Python was initially bundled so any problems
finding Python could be investigated.
Move this to use logging so we can show this information when needed.
`sys.executable` is documented to be a Python interpreter or None.
This was set to Blender's executable which caused the multiprocessing
module to spawn new instances of Blender instead of Python on WIN32.
See issue described in D7815.
Deprecate 'bpy.app.binary_path_python' & warn when using.
Blender's executable remains accessible via `bpy.app.binary_path`.
Modified 04c5471cee, setting `sys.executable` instead of using
Py_SetProgramName, which is needed for a bundled Python installation.
`sys.executable` is documented to be a Python interpreter or None.
This was set to Blender's executable which caused the multiprocessing
module to spawn new instances of Blender instead of Python on WIN32.
See issue described in D7815.
Deprecate 'bpy.app.binary_path_python' & warn when using.
Blender's executable remains accessible via `bpy.app.binary_path`.
Corrects incorrect usages of the word 'loose' when 'lose' was required.
Differential Revision: https://developer.blender.org/D9243
Reviewed by Campbell Barton
Using context overrides in Python caused problems for any operator that
changed the context and require these changes to be read back.
CTX_wm_area_set() for e.g. would set the struct member but future
calls to CTX_wm_area() would still return the value defined by Python
callers context overrides.
This also resolves a mismatch between polling and calling operators
from Python, where poll would override the Python context where calling
only overrode the context when a new context was passed in.
This commit renames 'execute' to 'run' because:
- This follows Python's "PyRun" which these functions wrap.
- Execution functions can use either exec/eval modes,
making naming awkward (for future API refactoring).
This was committed as a temporary workaround in 82150f5641
as release builds were failing (only debug builds worked).
This adds `stdio.h` to the header which is now split into a file that
contains more specialized functionality.
Also move function body inside BPY_python_backtrace,
removing PyC_StackPrint as we have PyC_StackSpit() for
similar functionality that can be called from a debugger.
As creator.c is used for the 'main' function,
avoid obscure declarations being placed so prominently.
- Move Blender as a Python module declarations into it's own section.
- Move USD declaration to an 'extern' just before it's called.
Showing the Python error without any explanation is often
not enough information and doesn't hint that the error was in the
user input.
The error report from a invalid expression such as '..1' used to be:
('invalid syntax', ('<string>', 1, 1, '..1'))
Now reads:
Error evaluating number, see Info editor for details: invalid syntax
Address issue raised by T78913.
Implementation of lerp without a function requires repeating one of
the arguments, which is not ideal. To avoid that, add a new function
to the driver namespace. In addition, provide a function for clamping
between 0 and 1 to support easy clamped lerp, and a smoothstep function
from GLSL that is somewhat related.
The function implementations are added to a new bl_math module.
As an aside, add the round function and two-argument log to the
pylike expression subset.
Differential Revision: https://developer.blender.org/D8205
This goes along with the existing changes to ignore PYTHONPATH by default.
--python-use-system-env now controls both.
Differential Revision: https://developer.blender.org/D6962
This avoids the problem where Blender doesn't start because
the PYTHONPATH points to an incompatible Python version,
see T72807.
Previously we chose to assume people who set the PYTHONPATH know what
they're doing, however users may have set this for non Blender projects.
So it's not obvious that this is the cause of Blender not to launch
on their system.
To use Python's environment vars, pass the argument:
--python-use-system-env
Note that this only impacts Python run-time environment variables
documented in `python --help`, Access from `os.environ` remains.
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
