Currently the GPU module for python has different ways to handle enums.
- Organizing items in `PyC_StringEnumItems` arrays and parsing them with `PyC_ParseStringEnum`.
- Using dedicated functions for each type of enum (`bpygpu_ParsePrimType`, `pygpu_ParseVertCompType` and `pygpu_ParseVertFetchMode`).
Although apparently more efficient (especially `pygpu_ParseVertCompType`
which transforms strings into integers for simple comparison), these
dedicated functions duplicate functionality, increase the complexity of
the code and consequently make it less readable.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D10456
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Mixing file rename with other changes should be avoided.
Using 'module_py_api' convention here
is in keeping with imbuf, idprop, blf & bmesh.
No reason for gpu to have a different convention.
Instead of crashing, an error message is displayed if a function of the gpu module is called without a GPU context.
Reviewers: brecht, campbellbarton, JacquesLucke, mont29
Subscribers: abdelmatinboulbayam, amir.shehata
Differential Revision: https://developer.blender.org/D4143
Using 'format' prefix made this read as if t was for string formatting.
Use 'PyC_StructFmt' prefix instead since these values are compatible
with formatting from Python's 'struct' module.