New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The project description is inaccurate #53
Comments
Thank you for your suggestion. The C module is entirely optional and will always be, and on top it's transpiled from a statically typed python like *.pyx module, hence the description. The pure python version will remain the gold standard, the C implementation is only a bonus for those who want to get some more speed. The documentation already quite clearly specify the existence of the C module, and the fact it is complimentary. |
Also for context, all other "Python Reed-Solomon codecs" are actually just wrappers around non-python implementations, so that you can't just edit the Python code, and the Python code is not sufficient (and in fact not doing much of the maths). Hence, to formalize my thought process, I consider as "Pure-Python" any Python package that does not require external non-Python tools to function. With this definition, which I believe is widely agreed on by other old time pythonistas, the outputs of a Python package do not matter. For example, I don't think anyone regard a Python package that generates DLLs or binaries, such as scripts entry points, as "non pure python". I think this is similar to a transpiled Cythonized extension. And this definition is not an adhoc post rationalization, I use it for every other Python package I have published so far. |
I'm afraid I have to disagree about the common use of "pure Python". At least what I've been taught is that "pure Python" means "no C code involved, so it won't segfault on me" (without getting into the details on how this is actually wrong ;-)). |
A word of context to my use of the term: Linux distributions often treat Python packages that don't include any non-Python code as "noarch", i.e. roughly equivalent to "purelib" wheels. On the other hand, packages that do install C extensions need to be built and tested on every architecture separately (i.e. "platlib"). Having "pure Python" in the description here has led me to initially wrongly believe this is the package of the former category. |
Thank you for your explanation. Would the following rewriting of the description be OK?
|
Please read the issue on GitHub, I have edited the description I have previously suggested. |
Yes, that is much more descriptive, thank you. |
Thank you for your feedback and your patience. It's now updated :-) I won't push to PyPi since no code has changed, but it will be pushed with the next bugfix! Have a great day and Merry Christmas! |
I'm sorry for being picky but the description right now says:
However, the default install includes a C module, so that's not really "Pure-Python" and could lead to confusion. Would it be fine to change that to just "Python Reed Solomon encoder/decoder"?
The text was updated successfully, but these errors were encountered: