Skip to content
This repository has been archived by the owner on Jan 31, 2024. It is now read-only.

Use Python dictionaries for internal input representation #121

Open
OndrejMarsalek opened this issue Jun 16, 2016 · 3 comments
Open

Use Python dictionaries for internal input representation #121

OndrejMarsalek opened this issue Jun 16, 2016 · 3 comments

Comments

@OndrejMarsalek
Copy link
Collaborator

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 😉

@ceriottm
Copy link
Collaborator

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?

On 16 June 2016 at 11:37, Ondrej Marsalek [email protected] wrote:

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 😉


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#121, or mute the thread
https://github.com/notifications/unsubscribe/ABESZ55qeASPkX-_VlvVthSDIdX2mNaGks5qMRlCgaJpZM4I3M3Q
.

@OndrejMarsalek
Copy link
Collaborator Author

Sure, I will prepare something so that we have specifics to discuss.

@ceriottm
Copy link
Collaborator

ceriottm commented Feb 3, 2017

@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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants