Closed mfripp closed 5 years ago
Is it possible to rename the switch_model.hawaii.util module to something different then? That might be a quick fix.
Yes, I can do that, or move the pyomo.environ import to the top so it doesn’t mask anything else. Shouldn’t be too hard, but I needed a note to remind myself to do it.
In the longer run it may be best to switch to import pyomo.environ as pyo
instead of from pyomo.environ import *
. That would make the code a little messier but also more ‘Pythonic’ and easier to understand.
Matthias
On Mar 5, 2019, at 3:08 AM, Benjamin Maluenda notifications@github.com wrote:
Is it possible to rename the switch_model.hawaii.util module to something different then? That might be a quick fix.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
+1 on quick fix of changing
this: import switch_model.hawaii.util as util
to this: import switch_model.hawaii.util as hi_util
+1 that a better long-term solution is to make the import more explicit somehow, and I agree with your pros/cons of using import pyomo.environ as pyo
. I reviewed the pyomo/environ/__init__.py
in their latest release, and there is no clear list of what is imported because they have nested layers of from pyomo.X import *
rather than defining __all__
with an explicit list.
If the pyo.
prefix was too cumbersome, we could make an explicit list of imports ourselves like so:
switch_model.pyomo_imports
from pyomo.environ import Set, Constraint, Param, Var, ... __all__ = ['Set', 'Constraint', 'Param', 'Var', ...]
Then normal modules would change
from pyomo.environ import *
tofrom switch_model.pyomo_imports import *
It appears this has been resolved in the short-term by importing our util module after pyomo. Ex:
...
from pyomo.environ import *
import switch_model.hawaii.util as util
...
As a perk, that solution is closer to the PEP 8 style guide for imports which recommends dividing imports into three sequential sections: standard library imports, 3rd party imports, and local applications imports.
As far as I know, our code base currently works with Pyomo v5.6.6 so I'm closing this issue as part of housekeeping. Please re-open if I am incorrect.
Pyomo 5.6.1 introduces some changes that can break Switch models. One is that it adds a
util
object topyomo.environ
, which masks autil
module imported inswitch_model.hawaii.save_results
, used by the main Hawaii model (users get "AttributeError: 'module' object has no attribute 'write_table'").I also saw problems (maybe the same one) when trying to run the advanced demand response model with Pyomo 5.6.1.
A quick fix is to roll back to Pyomo 5.1.1, but that is not sustainable long-term.