Currently, the indexes in the addVars can be ints or Iterable[_Scalar], where _Scalar = Union[int, float, str]. Can we allow Iterable[Hashable] instead?

In my project, mypy was complaining at the following code:

import gurobipy as gp

env = gp.Env.ClientEnv(
        logfilename="", computeServer="my_gurobi_server", password="my_password"
    )

Raising the following error: "Type[Env]" has no attribute "ClientEnv" [attr-defined]mypy(error)

And when investigating, I realized that the stubs for Env indeed do not include any attributes, only methods. It would be nice to modify the stubs to avoid needing to use type:ignore

I think NumPy's ShapeLike is this:

from typing import Sequence, Tuple, Union, SupportsIndex

_Shape = Tuple[int, ...]

# Anything that can be coerced to a shape tuple
_ShapeLike = Union[SupportsIndex, Sequence[SupportsIndex]]

Is our ShapeLike truly a subset of theirs? Would our use of ShapeLike actually allow their definition? We don't need to adapt to that kind of detail, but we should be aware of the consequences.

In the new version of gurobipy stubs, some functions start to return "Any" instead of _Scalar (for instance, getParamsInfo).
The main problem with "Any" is the following: "Any" means ignore type.
According to the "Åny" type documentation:
"Notice that no type checking is performed when assigning a value of type Any to a more precise type."
So, "Any" is the same as the absence of type but only looks nicer.
If you need to use a supertype of every type, it is better to use "object" instead of "Any"

It looks like while gurobipy allows for an Iterable of Hashable objects to be passed as index to addVars, the stubs only allow for an Iterable of _Scalar which is either int, str or float

Before pushing out the 2.0 release I'd like to confirm that "everything looks good" in VS Code and PyCharm.

Not sure what the usual practice is here. Installing the stubs will overwrite the type hints included with future gurobipy installs so we should try to prevent installing the stubs or at least warn the user.

gurobipy dependency version of the current packages on PyPI:

• gurobipy-stubs 1.0.x depends on gurobipy>=9.5.0 (we may want to post-fix these versions? or publish a 1.0.2 and yank the others so the user at least gets a loud warning)
• gurobipy-stubs 2.0.0 depends on gurobipy==10.* (nothing to do for this one, and no need to update setup.py on the master branch)