Open EvaSDK opened 7 years ago
sure, I never used the codecs module much but that sounds like a reasonable feature. A PR adding this is most welcome :)
Not sure I like the idea of using codext
. I'm currently looking into base58
because it is a very usable codec for one requirement for a new feature in the application: Generate short IDs which are human-readable.
As a developer, I don't really want to pull in a dependency that covers so many use-cases. I don't care about all the codecs supported by codext
. I only need base58. By having so many supported codecs inside codext
the probability of maintenance releases is increased and I don't necessarily want to fetch a new release whenever a codec updates that I don't use.
I prefer a well focused library that will only update when something in the base58 implementation needs fixing. Additionally, base58 is a simple algorithm and once the library stabilises, it's unlikely to need new updates.
So I opt against integrating this into codext
.
But having it integrated with the builtin codecs
package of Python would indeed be a nice-to-have.
Pondering this some again I would advice against using this with the codecs module. base58 is not a general purpose encoding of text or binary like utf16/zlib/base64 etc. Trying to encoding anything but small amounts of data is not a good idea as it relies on repeatedly doing divmod of the entire data represented as a single integer.
In any case, the registration would have to be done manually at some point by the users of this library. I did a library a while back for t61
encoding where I simply provide a register()
function to do this: https://github.com/exhuma/t61codec
This way, anyone who uses this base58
library can op to register it or not.
I am (currently at least) not aware if Python has a machinery that allows the execution of code just by installing a library. If there is, I'd love to learn about it. I'd wager that something like that could be abused by nefarious users, especially in combination with typosquatting.
Long story short: Offering the possibility to register with the codecs
module is harmless. If indeed a code-base needs to encode/decode with this codec fairly often in the code-base, something like this would indeed make the library more convenient to use:
import base58
base58.register()
That register
function could then also take additional "configuration" arguments, like, for example which alphabet to use.
But in the end it's only really providing a tiny bit of syntactic sugar.
And for those who don't want this, they can simply no call the register()
function.
It would be nice to allow this module to register its functions to the codecs module for easier integration. https://docs.python.org/2.7/library/codecs.html#codecs.register https://docs.python.org/3.6/library/codecs.html#codecs.register