Version 3.0.0 plan

[kan-fu]

Plan to release version 2.4.0 after pytest and documentation PRs are merged. This is to match the new documentation since from onc import ONC is not supported in 2.3.5.

After that, plan to introduce some breaking changes to 3.0.0.

• Change all the camelCase to snake_case. (Possibly include pylint in the linting tool). Aliases are kept for backward compatibility. (getLocations = get_locations)
• Remove all the util functions that is not used internally. This includes print and formatUtc methods in the ONC class, and the whole onc.util.util.py file. I doube any one would use them since there are no documentations.
• Code refactor (not necessarily break anything). I plan to get rid of _config method in _OncService.py as it makes it hard for the IDE to track the references of the instance variables of the ONC class. Also plan to use dataclass for ONC. I will elaborate my ideas later to ask for some suggestions.
• Include static type check (mypy) in CI (optionally). Not sure how much work that will need.

[kan-fu]

@danyalejandro Hi Dany, not sure if this message will reach you. My name is Kan. I am currently responsible in maintaining this repo.
I am planning to have a new release of the client libraries. I found that the client library in TestPyPI (https://test.pypi.org/project/onc/) did not have onc as the owner. Could you transfer the ownership to onc account? That would be greatly appreciated.

[Jacob-Stevens-Haas]

Big +1 on a dataclass for ONC.

Getting to static checking is a hard process. I've only recently done it in some of my repos, so my advice might be sketchy. Or maybe this is all stuff you're famiar with - sorry if so. But static typing is definitely helpful, and you can go one module at a time. It's more of a gradual process to be managed, accepting a certain amount of cast and type: ignore along the way.

From a backwards compatibility perspective, the biggest challenge is when a function accepts more types than it probably should. E.g. you need a collection to be covariant, but you've previously accepted list where you thus want tuple. In these cases the simplest solution is to restrict user input (breaking backwards compatibility), but it also works to accept a union or ABC and then explicitly convert within the function. e.g.

def foo(inputs: Union[list, tuple], params: Iterable) -> None:
    inputs = tuple(inputs)
    params = tuple(params)
    ... code that requires covariant containers

I've heard good things about MonkeyType, but haven't used it.

The other challenge is that the syntax for typing has evolved a lot in recent python versions, so things might be a bit more verbose until you can upgrade the minimum python version. I can take a look at beginning this process with something small, like util.py

[kan-fu]

Thank you for your suggestions. I will start type check after finishing the second (get rid of those unused util.py) and third task (easier to identify the type), so it probably will be in April or May.