Where to set default data - where received, or where used

[Dennis Carachiola]

I'm programming a project which will use a file to save parameters
needed by the program. There are already two previous file formats,
each of which can only be run by the version of the program which
created them. I'm trying to avoid that problem in the future. To do
that, I intend to use a dictionary, and default data. I believe that
most new versions will add parameters.

Each version of the program will have reasonable default values for
each key in the dictionary handled by that version. If an older file
is used, the data values in that file replace the keys that exist.
The program then can operate on the values supplied by the older data
file and the default values. Conversely, if a newer file is used, the
data in the file replaces the keys in the dictionary. The program
then simply doesn't access the newer data values. I'm hoping that
this will make the file backward and forward compatible.

Here's my question. I could do this by creating the dictionary with
the default values, then read the file into it. Or I could use a
'get' with default values at the location in the program where those
values are used.

From what I can see, creating the dictionary with default values puts
everything in one place. While, supplying the default values at the
place where they're used places the default values nearest the place
where actually used.

I can't decide on one way over the other. Can anyone give me some
ideas if one is a preferred method, or other criteria I've overlooked?

Thanks,

Den

[Dave Angel]

i would do it at the point of input. In fact, one option might be to
save an updated version of the file, with the missing fields filled in.
By doing it all in one place, you can test whether the code works with
each external variant you intend to support, and gives you one place to
fix whatever incompatibilities you find.

You very well might discover you need a fancier algorithm than just
having default values. For example, you might fill in missing values
with a computation based on the values you do have. Further, if it gets
really messy, you might end up with multiple input funcitons, keyed on
the type (version) of the file. The point is, none of the other code
should care one iota.

I certainly hope the version information for those existing files is
unambiguously stored.

--

DaveA

[Nick Cash]

This is really up to your programming style, but I'm of the opinion that defining all of the default values in one place keeps maintenance easier.

Of course, if it's done differently elsewhere in your code base, I would aim for consistency instead.

Thanks,
Nick Cash

--
http://mail.python.org/mailman/listinfo/python-list

[Chris Angelico]

On Tue, Jun 12, 2012 at 4:37 AM, Dennis Carachiola <dnc...@gmail.com> wrote:
> Here's my question.  I could do this by creating the dictionary with
> the default values, then read the file into it.  Or I could use a
> 'get' with default values at the location in the program where those
> values are used.

Both options have their recommendations. As others have said, setting
your defaults in one place has advantages of coherence; but setting
them at point of read keeps all the code using it together. You can
have an entirely dumb I/O submodule that feeds smart other-modules.
Take your pick based on what you're doing.

What I would definitely suggest, though, is making a structured config
file. (You could "cheat" by importing it as a module and making it
simply Python code.) Provide a template config file with lots of
explanatory comments, and (crucially) every config entry given,
commented out, and set to its default.

# Configures the default and maximum flurble percentages
# Flurblization increases from the default until either the maximum is
# reached, or max_sort_memory is exceeded, whichever comes first.
#flurble_default = 10
#flurble_max = 30

Having all your defaults in one place makes it easier to produce this
sort of file; in fact, you could have your documentation there as
well. It does become a little more maintenance work, though. It's
possible to have a hybrid, where you run a preprocessor over your code
that analyzes it, collects all config entries, and builds your config
file parser... but that may be beyond the scope of your project.

Anything you can imagine can be done in code. It's just a question of
how much work. :)

Chris Angelico