You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 31, 2024. It is now read-only.
I propose that we represent the input file structure internally as Python dictionaries (and lists or single values where appropriate). I also think this should be combined with the idea from some time ago to merge the input processing classes to the actual classes representing the various aspects of the simulation.
Input file parsing (and perhaps checking) would then happen in another separate layer that would be independent of the internal representation. This can be the current XML or other formats, supporting multiple formats would in principle be straightforward. Notably, it would also be possible to provide the input as a text representation of a Python dictionary, which will be useful for the emerging script interface.
Tools already exist to convert between Python dictionaries and XML, using XML processing from the standard library. I think this is the cleanest and most useful way to proceed. As a bonus, everyone on the different sides on the XML discussion should be happy 😉
The text was updated successfully, but these errors were encountered:
I'd like to see a proof of principle, although I am not sure how this could
be done without having a full-fledged implementation of the idea. Could you
try say to apply this to the "thermostat" object?
I propose that we represent the input file structure internally as Python
dictionaries (and lists or single values where appropriate). I also think
this should be combined with the idea from some time ago to merge the input
processing classes to the actual classes representing the various aspects
of the simulation.
Input file parsing (and perhaps checking) would then happen in another
separate layer that would be independent of the internal representation.
This can be the current XML or other formats, supporting multiple formats
would in principle be straightforward. Notably, it would also be possible
to provide the input as a text representation of a Python dictionary, which
will be useful for the emerging script interface.
Tools already exist to convert between Python dictionaries and XML, using
XML processing from the standard library. I think this is the cleanest and
most useful way to proceed. As a bonus, everyone on the different sides on
the XML discussion should be happy 😉
@OndrejMarsalek any progress on this front? Also, in the mean time I have created and used this InputDictionary thing that perhaps can be used -- or that largely removes the need for this improvement.
As you see we're trying to clean house so let's either do something in this direction or close this down until v3.0 -- that will probably be a complete re-write.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I propose that we represent the input file structure internally as Python dictionaries (and lists or single values where appropriate). I also think this should be combined with the idea from some time ago to merge the input processing classes to the actual classes representing the various aspects of the simulation.
Input file parsing (and perhaps checking) would then happen in another separate layer that would be independent of the internal representation. This can be the current XML or other formats, supporting multiple formats would in principle be straightforward. Notably, it would also be possible to provide the input as a text representation of a Python dictionary, which will be useful for the emerging script interface.
Tools already exist to convert between Python dictionaries and XML, using XML processing from the standard library. I think this is the cleanest and most useful way to proceed. As a bonus, everyone on the different sides on the XML discussion should be happy 😉
The text was updated successfully, but these errors were encountered: