Recent changes to feature-requests

UsingExtension flag to be externally accessible in Python 3

2019-01-24T19:18:45.850000Z

Add application access to the "usingExtension" flag so that applications using the crcmod package can determine if the c extension is being used or not. (Specifically for Python 3)

EX:
Adding the following line to /python3/crcmod/init.py

from crcmod.crcmod import _usingExtension

Allow "pure Python" installation

2010-05-19T02:07:43Z

While my primary dev environment is Linux, the actual users of my scripts will be on Windows machines. Currently the installation via easy_install is, realistically, a little complicated (and due to the nature of the 3rd party tools, liable to change, so writing step by step instructions will not necessarily help for very long).

The crcmod module *does* seem to have the capability of doing the maths without any native code, but installing via easy_install demands that the user compile the superfluous extension code nonetheless. (I mean, superfluous to my limited requirements; I understand the need for it under general circumstances.)

Would it be possible to install this package in a way that doesn't require compiling the native extension?

(I would have added this on the "Windows installation package" request, but it's closed.)

Documentation

2009-12-14T07:25:59Z

Some online documentation would be great.

* What versions of Python are supported
* API description
* Example usage

Windows installation package

2009-12-14T07:23:20Z

It can be a little tricky to install this on Windows, with the compiled extension. It would be nice for users to have a pre-built Windows installation package.

Support other code-generation options

2009-12-10T06:44:59Z

For small embedded systems, sometimes an 8-bit look-up table may be too large. It could be good to be able to generate C code for smaller versions of the CRC algorithm. Namely:

* 4-bit look-up (feed each byte in as two 4-bit nibbles, with a look-up into a 16-entry table)
* bit-by-bit calculation

Use class factory or metaclass

2009-12-10T06:41:56Z

Currently, the CRC lookup table is generated afresh each time a new instance is created with the normal class initialiser. You can get around this by creating new instances by "duplicating" another instance with either the copy() or new() methods.

A more natural solution would be to use metaclasses. A metaclass could create a CRC class for a particular type of CRC. The look-up table could be a class variable for each class so created. The lookup table could be generated when the first instance of the class is created. Then, the module could use the metaclass to pre-generate a bunch of well-known common CRC classes, such as CRC-32, CRC-16, CRC-CCITT, CRC-XMODEM, CRC-8, etc. See http://homepages.tesco.net/~rainstorm/crc-catalogue.htm for parameters for such CRCs. Then, users could generate class instances of the CRC class they want, using the more usual Pythonic syntax, and with efficient management of look-up tables behind the scenes.

Add option for final XOR

2009-12-10T06:26:36Z

Many CRCs have a "final XOR" which is applied to the reported CRC value. E.g. the standard CRC-32 has a final XOR of FFFFFFFF. This CRC module does not implement that, but it would be a useful addition.