On 2015-01-26 22:30, Ben Finney wrote:
Alex Kleider <aklei...@sonic.net> writes:
Please correct me if I am wrong, but I've assumed that it is proper to
define all functions before embarking on the main body of a program.
I would say rather that as much code as possible should be in small
well-defined functions, with the “main body” a tiny and trivial call to
a function.
That way, all the code is easily tested by unit testing tools.
I find myself breaking this rule because I want to set the default
values of some named function parameters based on a configuration file
which I have to first read, hence the need to break the rule.
Module-level constants are fine, and they obviously need to be bound
before the definition of the function which uses them for parameter
defaults.
But if they're not constants – as implied by your statement you read
them from a configuration file – then they should not be in the
function
definition, because reading the configuration file should itself be
encapsulated in a well-tested function.
Thanks for your well reasoned advice.
You are of course correct in that if they are read from a configuration
file then they are not constants but in a sense they are, at least for
the life of the current program run. I'm probably going to go with the
way Steve recommended which is to use global dictionaries to contain
the command line arguments (which docopt already does) and configuration
values (which are also placed into a dictionary by configparser) and
then
use those dictionaries within functions that need them
rather than setting default named parameters for the functions.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
