Well, Chris pointed out some bugs in my code, so a straight adaptation of the Arduino code is probably a lot more likely to be correct. I won't feel slighted if my pull request is rejected.

On the other hand, I prefer my code for my own use (go figure). If I'm working with Python code, I prefer to use things that work in Pythonic ways. Aside from the design of the classes and such, one conscious decision I made was to ignore a lot of the bit-twiddling the C code does to keep everything in the realm of integer arithmetic and embrace the fact that since I'm already running an interpreted language, floating-point math shouldn't hurt me too much.

==> I think there's some benefit in having an API that is similar to the Arduino code since there may be cases where code is ported from one platform to the other.

Math:

- The IainColledge module uses the integer math approximation from the data sheet for the lux calculation ("Simplified Lux Calculation")

- The asciiphil module uses the floating point math equations from the data sheet for the lux calculation

==> The floating point math should be more accurate, BUT the difference is in the noise compared to the +-40% accuracy of the sensor itself (see last entry in table on data sheet p.4), so this is really a wash

Coding style:

- The IainColledge module is not very object-oriented (only class is the Adafruit_TSL2651 class itself)

- The IainColledge module is not very "pythonic"; it is pretty obvious that it is translated C++ code

- The asciiphil module is much more sophisticated python code. It is truly object-oriented. It uses properties, decorators, docstrings, dictionaries, indexed lookups, exceptions, etc. It has better error checking.

==> The advantage of the IainColledge style is that it is easy to understand even for a novice programmer, and that describes the majority of this community. If the goal is to have code that is easy for this community to understand, debug, and modify/enhance then the IainColledge style is preferable. But if the goal is to have code that this community might actually learn to be better coders from, then the asciiphil style is better.

Features:

- The IainColledge module can be run standalone

==> Not necessary, but nice. Easy to add.

- The IainColledge module has an auto-gain feature

==> The auto-gain feature is very useful, so I think it should be added to the asciiphil implementation

- The asciiphil module has a "continuous mode" feature (which is actually the default)

==> Not sure how important this is to most people and it uses more power

- The IainColledge module returns a lux value of 0 when the sensor saturates

==> This matches the Arduino code, but is undesirable (IMO) since 0 is a valid value. I'd prefer that it returned a negative number.

- The asciiphil module throws an exception when the sensor saturates

==> This crashes the caller unless they know how to properly catch and handle exceptions. This is ok, but there should be example code for novice users

- The IainColledge module has an average lux calculation feature (not in Arduino code)

==> Nice, but not necessary. Easy to add externally.

- The asciiphil module automatically determines the package type from the ID register

==> Nice enhancement if anyone uses this code for anything other than the Adafruit TSL2561 breakout

Conclusions:

- With the bug fixes both of these implementations work fine

- I do think adding automatic gain selection to the asciiphil implementation is important

- Each (but especially the asciiphil version) could benefit by including a module of example code showing how to:

Of course the average lux calc can be useful. It just seems like a simple enough thing to do externally (unlike the automatic gain selection), so I wouldn't penalize Phil's code for not having it.

BTW, the bulleted feature list at the top of the data sheet says "Automatically Rejects 50/60-Hz Lighting Ripple". That's the only mention, however, and I wonder if it is true in the 13.7ms integration time mode since 50Hz is a 20ms period and 60Hz is a 17ms period. It's also notable that they say "ripple" and not "flicker".

Have updated the code using the inspection capabilities in PyCharm and SonarQube so at least it looks like Python now, there are three things that need looking at which I've flagged with TODO's but will have to look at them some time in the near future.

okay... this is a bit embarrassing... even though I haven't been able to get the AdaFruit_GPIO /-I2C libraries to work, I finally thought to expand my google search beyond the 'AdaFruit Universe' and found this post (in german):