New: Return default value of fieldvalue when possible#252
New: Return default value of fieldvalue when possible#252samuelduchesne wants to merge 20 commits into
Conversation
| """parse the fieldvalue type into a python type. eg.: 'real' returns | ||
| 'float'""" | ||
| _type = next(iter(epbunch.getfieldidd(name)['type']), None) | ||
| if _type == 'real': |
There was a problem hiding this comment.
We have integer as a type which can be handled here. There are also alpha, which you already handle, and choice and object-list which I'm not sure how (or if) they need handling.
There was a problem hiding this comment.
If you search an IDD for those last two, it might give you ideas on what we need do with them.
Also, watch out for "AUTOCALCULATE" value which can appear in fields with real (and maybe integer) type. Probably best to add it as a test case.
There was a problem hiding this comment.
This isn't resolved as it doesn't yet handle "AUTOCALCULATE".
There was a problem hiding this comment.
Not sure I understand why returning the string "autocalculate" is not ok.
There was a problem hiding this comment.
It's used in fields which are marked as real, so will end up calling float("AUTOCALCULATE") which will raise a ValueError.
Sounds like a useful addition to me. |
Also, refactors the test_bunch_subclass so that pytest fixtures are used
Since __getattr__ now returns the default value when a fieldvalue is not provided, asserting that Do_Zone_Sizing_Calculation will return "No" weather or not defaultvalues=True or False. Although the repr() of the EpBunch still behaves properly and won't print the default values. I think this is the correct behavior.
… empty string If an empty string is returned, will try to return the default value instead if it exists. This behavior is compatible with the the way EnergyPlus handles missing fields
…ifferent than "eplus" Now uses glob with a wildcard to catch the first *out.err file
Running these tests locally with env var EPPY_INTEGRATION=1 would throw errors on EnergyPlus' side; it asks for the expandobject subroutine
This reverts commit fd8789c.
… the `extractidddata`
samuelduchesne
force-pushed
the
feature/defaults
branch
from
7f94f6a to
a84753c
Compare
…ut keeps same behavior tests are happy
2 participants
@santoshphilip, @jamiebull1
Hi guys, completely unrelated to the decorators pull request; I encountered a situation where I needed the default value of a fieldvalue when it is not specified in the IDF file. For example, an OpaqueMaterial that does not have the Solar_Absorptance value defined will return "" instead if the default value set in the IDD for that field (0.7).
I simply added a condition in getattr to check if 'default' is in the fieldidd, and if so to return the value. Since the type of the value is also provided ('real', 'alpha', etc.), I created a simple type_parser that translates the idd-defined type to a Python type (eg.: 'real' => 'float')
The type_parser should probably include all possible types in an IDF file. Don't know how to get the complete list of possibilities. Ideas?