Linting and Typing

[ntjohnson1]

I used #54 as an example of the result for adding typing and linting to the tensor class. These are not coupled so we could take one without the other but wanted to make sure we discuss before applying either broadly across the code base.

Linting (I specifically like pylint but am open to alternatives)

To start with the linting can be opt in as we work our way across the code base. However the fixes will create churn that potentially complicates merging in changes occurring in parallel.

Pros:

• It suggests improved python style that should make things more consistent across the repo and arguably more readable
• It does basic static analysis checks so can catch typos or other logic errors that might not get covered from unit test

Cons:

• Pylint is opinionated so people might potentially disagree with it (I would prefer to opt out of certain rules of exempt certain lines rather than 0 coverage)
• It takes about 20-30s on my laptop to run it compared to the current ~5s it takes for all our unit tests so impacts developer experience

Typing (enforced with mypy since that's pretty standard)

Right now we don't have any typing so we could turn on mypy to enforce whatever we add so can do it incrementally. Today I think typing is only used for expressiveness and doesn't have any meaningful functional impact. Eventually that may change but I don't think there is any real roadmap around it. I know some tools build on top of typing but I don't think we were specifically targeting any of those.

Pros:

• Right now we define types in our numpy style doc strings, however those aren't tested directly. If we switch to types that's both clearer in my opinion since much of the ecosystem is moving towards types AND mypy can run static tests to ensure correct behavior based on our types.
  • Arguably typing lets us be even more expressive on typing assumptions for example where the types of arguments impacts the types of returns

    pyttb/pyttb/pyttb_utils.py

    Lines 153 to 163 in e5cedce

    	@overload
    	def tt_dimscheck(dims: np.ndarray, N: int, M: None =None) -> Tuple[np.ndarray, None]:
    	...
    	@overload
    	def tt_dimscheck(dims: np.ndarray, N: int, M: int) -> Tuple[np.ndarray, np.ndarray]:
    	...
    	def tt_dimscheck(dims: np.ndarray, N: int, M: Optional[int] =None) -> Tuple[np.ndarray, Optional[np.ndarray]]:

• Adding type coverage may find edge cases where we don't properly support the types we expect
• mypy runs real fast so no slowdown seen so far
• If we add typing to all the base tensor types then downstream users can use the types or totally ignore it. It doesn't adding any downstream dependence
• Exploring the types shows we might have some circular dependencies related to pyttb_utils both using and being used by tensor types

Cons:

• The types can get a little messy. As we initially add types I expect them to first be fairly specific then we can probably identify common types to simplify
• People might not be familiar with typing so it might make it slightly more challenging for people to contribute, however I expect once the groundwork is laid adding onto it to not be too cumbersome.

[ntjohnson1]

Here's a post from the python subreddit that seems to align with the general direction/tooling. https://www.reddit.com/r/Python/comments/11pah4o/an_opinionated_python_boilerplate/

[ntjohnson1]

Closing discussion since the repo now has linting and typing coverage.