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 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, 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_module, 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.
- RNA API: Unify handling of singleton custom-data layers.
Currently there exists Mesh.vertex_paint_masks and Mesh.skin_vertices, these are exposed as lists of layers, but there are only ever single layers.
The API doesn't yet support a nice way to handle this, but we could add a generic way to expose singleton custom-data layers.
- Remove addons paths from Python's sys.path, This means addons won't be able to be imported directly.
Benefit: Avoid polluting the module namespace, since there is no reason add-ons need to be visible globally from any other Python script.
- 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
Benefit: Minor speedup
- 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 A. Stüvel (sybren): We could start using @ for matrix multiplications (of which the dot product is a specialisation); see PEP 465. 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.