英文:
subclassing Pyomo model for auto-completion / type hinting
问题
I'm considering implementing a schema as below for one of my larger pyomo projects. (Yes, I'm intentionally using m instead of the ubiquitous self for consistency in the model.) In the project, the model creation / solving / post-processing are all separate modules, and I'd like to be able to employ the IDE's auto-complete and type hinting on the model, which would make it quicker / more accurate to locate key variables, sets, etc. in the post-processing and tidy up the project.
I'm considering sub-classing ConcreteModel to do this.
Is this a good/horrible idea?
Are there other options for achieving this?
I've seen this posting which indicates sub-classing has been considered for other reasons.
import pyomo.environ as pyo
class MyModel(pyo.ConcreteModel):
def __init__(m):
super().__init__()
m.S = pyo.Set(initialize=[1, 2, 3])
m.x = pyo.Var(m.S)
@m.Constraint(m.S)
def upper_limit(m, s):
return m.x展开收缩 <= 5
# ... etc.
m1 = MyModel()
# meanwhile.... somewhere else in post-processing:
def list_set_vals(m: MyModel) -> list[int]:
return list(m.S) # <-- auto-completion available
print(list_set_vals(m1))
英文:
I'm considering implementing a schema as below for one of my larger pyomo projects. (Yes, I'm intentionally using m instead of the ubiquitous self for consistency in model.) In the project the model creation / solving / post-processing are all separate modules and I'd like to be able to employ the IDE's auto-complete and type hinting on the model, which would make it quicker / more accurate to locate key variables, sets, etc. in the post-processing and tidy up the project.
I'm considering sub-classing ConcreteModel to do this.
Is this a good/horrible idea?
Are there other options for achieving this?
I've seen this posting which indicates sub-classing has been considered for other reasons.
import pyomo.environ as pyo
class MyModel(pyo.ConcreteModel):
def __init__(m):
super().__init__()
m.S = pyo.Set(initialize=[1, 2, 3])
m.x = pyo.Var(m.S)
@m.Constraint(m.S)
def upper_limit(m, s):
return m.x展开收缩 <= 5
# ... etc.
m1 = MyModel()
# meanwhile.... somewhere else in post-processing:
def list_set_vals(m: MyModel) -> list[int]:
return list(m.S) # <-- auto completion available
print(list_set_vals(m1))
答案1
得分: 1
我不认为这样做会有明显的问题（而自动完成肯定是一个不错的好处）。ConcreteModel 实际上只是在 Block 之上的语义糖，只要不更改类/实例的 ctype（它仍然应返回 Block），那么诸如求解器和转换等内容应该仍然能够正常工作。
其他项目已经广泛使用了对 Block 进行子类化（例如，IDAES），尽管在那里的目标是支持索引子类，因此实现标量和索引组件的基础设施略微复杂一些。
此外，Pyomo 早就应该重新组织/扩展标准示例了。我认为将这个用例添加到标准集合中是个不错的主意 - 请考虑向该项目提交它。
英文:
I don't see any obvious pitfalls with doing that (and autocompletion would certainly be a nice benefit). ConcreteModel is really just semantic sugar on top of Block, and as long as you don't change the class / instance ctype (it should still return Block) then things like the solvers and transformations should still all work the same.
Other projects have made extensive use of subclassing Block (e.g., IDAES), although there the goal is to also support indexed subclasses, so the infrastructure to effect both scalar and indexed components is a little more complex.
Separately, Pyomo is way overdue on reorganizing / expanding the standard examples. This use case strikes me as a nice one to add to the standard set -- please consider submitting it to the project.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论