can we please get rid of the isascii assertion on variables?

[ExpandingMan]

I'm assuming the reason for this is that Gurobi only officially supports setting variable names to ASCII, but in Julia, where unicode is ubiquitous this is incredibly annoying, and clearly most things work perfectly fine even if you use non-ascii strings.

Could we simply delete the assertions in get_attrs.jl?

[odow]

Do you mean
https://github.com/JuliaOpt/Gurobi.jl/blob/ffdc849eab5782a22803c06c2e6bb22ffebe0242/src/grb_attrs.jl#L243
and
https://github.com/JuliaOpt/Gurobi.jl/blob/ffdc849eab5782a22803c06c2e6bb22ffebe0242/src/grb_attrs.jl#L254

clearly most things work perfectly fine even if you use non-ascii strings.

Do you have examples? Does Gurobi throw an error? If so, what? Can you round-trip unicode strings?

[ExpandingMan]

Yes, those are what I mean. I know that Gurobi itself does not throw an error, because I've been using unicode strings since the beginning and never had a problem. I haven't explicitly tried to round trip the strings, but it must work because there is never a problem in retrieving the variables.

In the case of variables it's possible to investigate this with, for example, @variable(m, α)

[odow]

We could accept a PR with tests showing that it works okay doesn't cause a terrible error.

[odow]

because I've been using unicode strings since the beginning and never had a problem

One difference is that now we push the strings through to the solver, whereas JuMP used to cache them at the Julia level and the solver never knew what they were named.

[ExpandingMan]

Ah, ok I didn't realize there was an actual difference. I'm going to try it and see if it works.

I'd really hate to have to use all ASCII variable names for Gurobi all the time, so if it doesn't work I'll start looking into work arounds.