Currently, the package uses the C++ code by default and leaves the use of the pure Python implementation to the discretion of the user.
It might be better to more clearly separate the Python and C++ implementation. Some ideas:
provide separate "strincompare" and "cstringcompare" packages,
at package load time, try using C++ implementation and fall back on the pure Python implementation if loading fails.
There are also some issues with having all C++ code in headers. Compilation is still very quick but I'm not sure how it will scale as the package grows. It would also be nice to be able to provide the C++ code as a C++ library which is independent of the Python implementation...
We'll see what refactoring is needed as the package grows.
Currently, the package uses the C++ code by default and leaves the use of the pure Python implementation to the discretion of the user.
It might be better to more clearly separate the Python and C++ implementation. Some ideas:
There are also some issues with having all C++ code in headers. Compilation is still very quick but I'm not sure how it will scale as the package grows. It would also be nice to be able to provide the C++ code as a C++ library which is independent of the Python implementation...
We'll see what refactoring is needed as the package grows.