List Problem?

[santaimpersonator]

Might need to use list function instead of brackets [<blah, blah...>] to list address. Currently, doesn't affect functionality.

https://github.com/sparkfun/Qwiic_TCA9548A_Py/blob/74ba5b13c3f99f7707c4261a26623a5b2aff8c28/qwiic_tca9548a.py#L70

In reference to this issue: sparkfun/Qwiic_Py#7

[wickedbeernut]

Forgive my ignorance, but ...

Why hasn't this been resolved? Am I expected to edit my local (installed) copy of qwiic_tca9548a.py? Is the issue limited to _AVAILABLE_I2C_ADDRESS? Am I the only one having the same issue with available_channels? Why can't you explicitly list out the available I2C addresses and channels, rather than using the range syntax?

# Some devices have multiple availabel addresses - this is a list of these addresses (0x70 - 0x77).
# NOTE: The first address in this list is considered the default I2C address for the
# device (0x70).
# _AVAILABLE_I2C_ADDRESS = [*range(0x70,0x77 + 1)]
_AVAILABLE_I2C_ADDRESS = [0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x77]

        # Available Channels:
        # available_channels = [*range(0,7+1)]
        available_channels = [0,1,2,3,4,5,6,7]

[santaimpersonator]

@wickedbeernut Your comment was hidden because it doesn't pertain to this issue. This issue is about using the list() function instead of placing the addresses in brackets. It's just an alternative method for doing the same thing. I was thinking the modification could have helped with the referenced issue, but that is not the case if you read through the referenced issue.

The code you are referring too ([*range(0x70,0x77 + 1)]) does exactly what you are suggesting as a fix ([0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x77]). (*The range() method is just a more efficient way of coding than manually typing out each individual address.) Unfortunately, I couldn't determine the rest of your problems as they were posed in questions and the problem was not described sufficiently. For more information on this package, please refer to the hookup guide and the ReadtheDocs page.

In the future, the issues tab is not used for technical assistance. If you have a valid issue with the code please file a separate issue with a brief description of the problem, documentation of the problem (code, testing platform, error messages, etc.), and information about your setup. Otherwise, for technical assistance, please post a topic on our forum.

[gregkrsak]

This suggestion makes no sense to someone who is learning python, and (very delicately) is certainly not representative of what SparkFun stands for, in my opinion.

Respectfully requesting removal of the wontfix label, with a corresponding solution.

Just so there is no miscommunication: sudo pip install sparkfun_qwiic on Raspbian / Raspberry Pi with uname -a showing 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux does not install working code for the red (non-SparkX) Qwiic Multiplexer as of the date/time of this comment.

[santaimpersonator]

@gregkrsak As mentioned in the hookup guide, please use pip3 instead of pip. Python 2 is deprecated and no longer has continued support.

• I just filed a new issue to consider updating instructions for all our Python packages, since some packages (i.e. submodules) are having compatibility issues.

In the future, for technical assistance, please create a topic on our forum.

---

In regards to the first part of your comment, I am not sure I understand. Could you clarify your confusion in the issue details? Did you expand the hidden comments above?

• This issue is technically, for our internal use, on the standardization of listing I2C addresses.
  • There is a partial explanation in my hidden comment above
• Repository issues are not meant for users to learn how to code. They are for documenting/tracking problems in the repository.
  • Especially, open issues... as they are "unsolved" (and have no solution yet).
• The issue in your comment has nothing to do with this issue and should have been submitted as a new issue
  • That being said, I am going to hide your comment and this one, since they don't pertain to the topic of using the list() function for the I2C addresses

This issue has a wontfix label because technically there is no functionality problems with the code. As mentioned above, it's just a standardization thing for us.

[gregkrsak]

We have philosophical and communication differences, for certain. But check this out: This is going to make me look stupid (which is partially true), but I forgot Python 2 still existed in the wild. I've only ever used Python 3.

[santaimpersonator]

@gregkrsak In short this issue, is just for me an 2 other people to keep track of how/if we want to standardize our method for listing I2C addresses in the code. There should be no problems with the package (beyond updating the installation instructions in the README.md file).

Is it safe to assume that pip3 fixed your installation problem?