[Python-ideas] Framework for Python for CS101

[Terry Reedy]

On 5/26/2015 2:07 AM, Chris Angelico wrote:
> On Tue, May 26, 2015 at 3:54 PM, Terry Reedy <tjreedy at udel.edu> wrote:

>> Programming is composition, the connections of outputs to inputs (as with
>> circuit design).  'Print' is the enemy of composition. We agree so far.
>
> That's fine as long as it's okay to produce no results whatsoever
> until all processing is complete.
> In a pure sense, yes, a program's
> goal is to produce output, and it doesn't make a lot of difference how
> that output is produced. You can build a web framework in which the
> only way to send a result is to return it from a function. But there
> are innumerable times when it's more useful to produce intermediate
> output; whether that output goes to a file, a socket, the console, or
> something else, it's as much a part of real-world programming as
> returned values are.

The context is a beginning programming course where the goal is to teach 
people to write

def f(a, b, c): return a*b + c
print(f(2, 3, 4))

instead

def f(a, b, d): print(a*b + c)
f(2, 3, 4)

In other words, to teach beginners to relegate output to top level code, 
separate from the calculation code. (Or perhaps output functions, but 
that is a more advanced topic.)  The first function is easy testable, 
the second is not.

For printing intermediate results, yield lines to top-level code that 
can do whatever with them, including printing.

def text_generator(args):
    ...
        yield line

for line in text_generator: print(line)

is top-level code that prints intermediate results produced by a 
testable generator.

People want to see results, which is half of why I said not to delete 
print.  But proper assignments and grading can enforce separation of 
calculations from use of results.  The idea of separation of concerns 
did not start with OOP.

-- 
Terry Jan Reedy