Remove the export decoration on implementations. The details are indirected
through a pointer to the data. There is no need to make the data itself
visible. This was detected during work to support Windows/MSVCRT.
These two symbols were not correctly scoped, placing them inside of the swift
namespace. This would change the linkage names and fail to link as a result.
Scope one as the header properly places it in an extern "C" block. The gyb file
is unable to find the desired runtime header, so explicitly mark the exported
symbol as being exposed with C linkage.
The repo contains roughly 80 Python scripts. "snake_case" naming is used for
local variables in all those scripts. This is the form recommended by the PEP 8
naming recommendations (Python Software Foundation) and typically associated
with idiomatic Python code.
However, in nine of the 80 scripts there were at least one instance of
"camelCase" naming prior to this commit.
This commit improves consistency in the Python code base by making sure that
these nine remaining files follow the variable naming convention used for
Python code in the project.
References:
* PEP 8: https://www.python.org/dev/peps/pep-0008/
* pep8-naming: https://pypi.python.org/pypi/pep8-naming
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.