Luke Marshall

Good call. There are a few options: 1. The user can explicitly call the base method via: super(highspy.Highs, h).addVar(...) 2. We can add a new method to highspy to call...

Alternatively, we could rename the base class method `addCol`, to be similar to `addRow`, which implies low-level functionality.

I totally agree that advanced users will likely want to access `Highs` directly, in which case they might prefer the low-level and bulk update calls anyhow. Also, there is a...

Correct, this was by design so that we can efficiently add a batch of variables. It's not ideal for people to add many variables one-by-one - but obviously it's still...

BTW: I believe with the new highspy, mats.py can be rewritten from: ```python for i in range(nvars): h.addVar(0, inf) h.changeColCost(i, 1) row_nnz = 2 index = np.array([0, 1]) value =...

Good point. Referring to comment in #1679, if we also support `addVars/addConstrs` in highspy, we could simplify even further: ```python X = h.addVars(nvars, obj=1) C = h.addConstrs(X[i] + X[i+1] >=...

That highspy code would look something like the following: ```python def addVars(self, nvars, lb = 0, ub = kHighsInf, obj = 0, type=HighsVarType.kContinuous, name_prefix = None): return [self.addVar(lb, ub, obj,...

This is a simple feature (if we limit to linear expressions). I've already added support in #1891. Will commit when I've finished with all the new tests and suitable highspy...

Apologies, I was travelling in the last 2 weeks. I can replicate, however it's not `addVariable` that's causing the performance hit. It's actually the **variable naming**, i.e., h.addVariable(lb=0, **name=f"z{k}"**, type=highspy.HighsVarType.kInteger)....

This is a good comment for discussion. There are 2 main reasons why `highs_linear_expression` isn't immutable: the ability to express constraints like `5