What system? The GBA and DS share a common type, though the DS has a few more, but the 3ds switched things up a bit and the GC/Wii also have their own takes on things.
For simple GBA compression most would point you at GBA crusher
http://members.iinet.net.au/~freeaxs/gbacomp/#GBA Crusher
For the GBA/DS Cue's compression tools are worth a look and have source available
http://filetrip.net/nds-downloads/utilities/download-cues-gba-ds-compressors-1-0-f29010.html
If you had already seen this then make sure you did pull apart the normal ones -- Cue also made a version which was compatible with the Nintendo decoder but better than what Nintendo had done, indeed something like that might be the story everywhere (who cares if it is a byte for byte match if the decoders handle it just the same either way?).
I should also link
https://github.com/barubary/dsdecmp
Crystaltile2 has some options here
http://filetrip.net/f23649-CrystalTile2-2010-09-06.html
Also worth noting here is the DS binary compression used in DS ARM9 binaries and overlays. Technically it would be known as BLZ and covered by cue's tools at least.
I am not sure what is out there in some flavour of open source in python but if you only need to compile it or can call something then it should not be so bad.
Not sure what people are using for GC/Wii stuff right now. The classic thing to deal with is called YAZ0
http://www.amnoid.de/gc/yaz0.txt and on the Wii there was a lot of u8 compression which many would handle with something like U8Tools
I should also mention the option to cheat. Why recompress and handle the aggravation of sliding window search and encoding if you can just set flags to next ? bytes are uncompressed instead. Similarly with BLZ in the DS binary then there is a little table in the header/referenced by the header so you can set it to uncompressed, I have seen such tables in a few other games as well.
