This task is to collect changes (possibly breaking changes), that may go into 2.8x.
//Note: Python3.6, builds and runs without any problem with current master it seems, all tests pass OK too, so would not expect any issue switching to it once we are ready.//
- Use Python 3.6 [[ https://www.python.org/dev/peps/pep-0498 | Literal String Interpolation ]] for all string formatting.
**Benefit:** more readable, and faster evaluation than modulo or format method.
**Update:** this is planned some weeks after 2.79 release (allow time for 2.79a if needed). 2.8x branch will also use Python3.6.
- Use keyword only arguments for internal API's for optional arguments which adjust function behavior //(can be decided on case-by case basis, [[ https://www.blender.org/api/blender_python_api_current/bpy.utils.html | bpy.utils ]] is an example where keyword only arguments can be used for most options)//
Benefit: ability to extend API without worrying about argument order, also more readable code.
- Support keyword only arguments for RNA API.
Benefit: We can adjust keyword usage without worrying about callers that rely on argument order.
- Remove `bpy.utils.register_modules`, already done for default configuration, only addons remaining (see patch to assist with this: P455)
Benefit: Remove internal code that currently needs to keep track of a classes module when its registered. Also prefer explicit over implicit classes for registration.
- Replace term `median` with `mean` (incorrect use was all over C code and leaked into Python API): `Matrix.median_scale`, `BMFace.calc_center_median`, `BMFace.calc_center_median_weighted`.
- Rename `IDProperty.iteritems()` to `items()`, //(convention from Python2, with Python3 `items()` is default)//, note that it seems no scripts used `iteritems()`, though its possible they depend on `items()` being a list instead of an iterator.
- Add an 'API version' number in addition to Blender's version system.
It would be a simple integer, increased every time we change something to Blender API (either directly in py modules, or through RNA API).
Benefit: while addons in our own repositories (and distributed with Blender) are expected to always be compatible with current master, third party addons could use it to do their own versioning management - current Blender version number (which mostly reflects serious changes done to data model) is not precise enough here.
- BMesh Operator API currently has `enum` type arguments which are passes as ints from `bmesh.ops` API.
This should be made into something similar to RNA enums (so Python can pass in a string identifier).
Benefit: Python developer's don't need to guess what magic numbers do.
- Change: Use Python3.6 `__init_subclass__` for `bpy_rna.c` class creation https://docs.python.org/3.6/whatsnew/3.6.html#whatsnew36-pep487
Benefit: Faster startup and addon registration.
- Use `_PyArg_ParseTupleAndKeywordsFast` for faster argument parsing https://bugs.python.org/issue29029
- Change / remove `bpy.app.handlers.scene_update_pre`, This is currently running **continuously** because of changes to scene evaluation, many scripts abuse it to execute functions many times a second.
Since the original purpose of this callback is no longer working as expected, we should make this run only on scene updates, or - remove it.
Benefit: Add-on's should remain fast and not slow down Blender by running code continuously.
- Change behavior or Vector multiply & divide, see discussion on D1743.
@sybren: We could start using `@` for matrix multiplications (of which the dot product is a specialisation); see [PEP 465](https://www.python.org/dev/peps/pep-0465/). We can then keep `*` and `/` for scalar multiplication/division only.
Benefit: Ability to perform element-wise division/multiplication.
- Investigate supporting `asyncio`.
Benefit: Better options for performing asynchronous operations.
Notes: Currently, code that wants to use asyncio has to handle its 'loop kicking' itself, usually by adding its own timer. Idea could be rather to have a single generic 'subloop' timer, only running on demand, to which all scripts could subscribe (probably via a new callback ?).
- Replace our own auto-completion with Python's for the Py-Console //(more a general TODO)//.
Benefit: Less code for us to maintain (this isn't and urgent task though).
- Use type hints //(since these are very new, we can take a *wait and see* approach, but seems like these could be useful - and could be automatically set for RNA API's).//
Benefit: Better support code introspection and static checkers.