Scipy currently includes an lti class, however, this has some issues and overheads and is not always used in a consistent way:

1. It is stated to be limited to continuous time systems, but is then abused for discrete time ones when used as a parameter in dlsim, dlstep, dimpulse, etc.

2. It creates a non-consistent treatment of continuous and discrete-time systems, since for continuous ones impulse, step and output response can be obtained directly from the class, while for discrete ones it compels to use extra functions, passing the class as a parameter.

3. It incurs an overhead since it memorizes at the same time all the possible representations of the system ('tf', 'zpk' and 'ss') and recomputes all of them whenever one is changed, rather than lazily obtain the representations only as needed.

I suggest fixing 1), 2) and 3) by either

PLAN A (minimal)

Add a timestep parameter to the class (e.g. T). When this is 0, the system is continuous time, when it is 1, the system is discrete time. This would let all the methods present for the current LTI class also work for discrete time systems.
Then getters could be used to update the representations, rather than setters, to avoid unneeded overheads.

PLAN B

Create a proper LTI hierarchy, where an abstract LTI is subclassed in a continuous time and a discrete time one, as well as a 'tf' (ba), 'zpk' or 'ss' representation for each. Let each subclass of 'tf', 'zpk' or 'ss' accept each other class in initialization, to convert between representations.

Probably A is easier and easier to make compatible with the current code base, but B is more elegant and makes better advantage of an object oriented language like Python.