On 10.08.2014 00:30, Terry Reedy wrote:
The advantage of TDD is that it forces one to make code testable as you do.
Thanks a lot, Terry, for your comprehensive example!
--
https://mail.python.org/mailman/listinfo/python-list
On 8/9/2014 2:14 PM, Fabien wrote:
On 09.08.2014 19:29, Terry Reedy wrote:
If possible, functions should *return* their results, or yield their
results in chunks (as generators). Let the driver function decide where
to put results. Aside from separating concerns, this makes testing much
easier.
On 09.08.2014 19:29, Terry Reedy wrote:
If possible, functions should *return* their results, or yield their
results in chunks (as generators). Let the driver function decide where
to put results. Aside from separating concerns, this makes testing much
easier.
I see. But then this is also true
On 8/9/2014 7:48 AM, Fabien wrote:
BUT, my "problem" is that several options really are "universal" options
to the program, such as the output directory for example. This
information (where to write their results) is given to most of the
functions as parameter.
If possible, functions should *r
Hi,
On 09.08.2014 18:16, Dennis Lee Bieber wrote:
Better, in my view, is to have the import module set up default values
for everything, AND have a function at the bottom of the form
def initialize(fid=None):
if fid:
# parse file "fid" replacing the module level items
On 2014-08-09 13:48, Fabien wrote:
> So I had the idea to define a super-object which parses the config
> file and input data and is given as a single parameter to the
> processing functions, and the functions take the information they
> need from it. This is tempting because there is no need for
>
Hi Ben,
On 09.08.2014 14:17, Ben Finney wrote:
Have one module of your application be responsible for the configuration
of the application::
# app/config.py
import configparser
parser = configparser.ConfigParser()
parser.read("app.conf")
Thanks for the suggestion. This w
Fabien writes:
> So I had the idea to define a super-object which parses the config
> file and input data and is given as a single parameter to the
> processing functions, and the functions take the information they need
> from it.
That's not a bad idea, you could do that without embarrassment.
Folks,
I am not a computer scientist (just a scientist) and I'd like to ask
your opinion about a design problem I have. It's not that I can't get my
program to work, but rather that I have trouble to find an "elegant"
solution to the problem of passing information to my program's elements.
I
