[Python-ideas] where statement in Pyret

[Steven D'Aprano]

On Sun, Nov 10, 2013 at 10:55:16AM +0100, Tarek Ziadé wrote:
> Hey
> 
> I've read about Pyret on hackernews: http://www.pyret.org/

Looks very interesting.


> and found the 'where' statement very compeling. Functions can end with a
> where that contains small unit tests.
> 
> From the documentation example:
> 
> fun sum(l):
>   cases(List) l:
>     | empty => 0
>     | link(first, rest) => first + sum(rest)
>   end
> where:
>   sum([]) is 0
>   sum([1, 2, 3]) is 6
> end


Sadly, I *really* dislike that. To me, "where" has absolutely nothing to 
do with testing. I see that Pyret also includes a "check" keyword which 
also does testing. That seems like a more sensible keyword.

I would prefer to see some variation on Nick Coglan's ideas about a 
"where" keyword for local scoping of temporary variables. This is an 
idea that's been floating around for a long time:

https://mail.python.org/pipermail/python-list/2005-January/329539.html

Quite frankly, although I believe that tests are of vital importance, I 
remain to be convinced whether they should be "a first-class citizen of 
the language" as you put it. In my experience, for every line of code 
you write, you'll probably need anything from 3-10 lines of test code. I 
don't think that much test code belongs in the same module as the 
function itself -- that's an invitation to have people stint on their 
testing. Look at the example given -- do you really feel that this is 
sufficient testing for the sum() function?

I don't object to having a few, simple, fast tests in the main module, 
but for "real" unit testing and regression testing, they ought to be 
moved out into a separate file. Tests are often, usually, boring code 
which just distracts from the code you care about. I would hate to see 
it become common to have something like this:

def some_function():
    # 20 lines of code
where:
    # 170 lines of tests

become standard.

But in any case, I think it is far too early to be thinking about 
stealing an idea from Pyret. The language isn't even stable yet, let 
alone at the stage where this idea has proven itself in the real world. 
Pyret and the where clause is still experimental.


> It's quite similar to the doctests ideas I guess - but not intended to
> be documentation like them.
> 
> I ended up disliking docttests because of this doc+test duality by the
> way: it often ends up as a
> not so good documentation and not so good tests.

In my experience, people who write poor doctests would write equally 
poor unit tests, or "where" tests if Python had this feature.


> Anyways, having a dedicated keyword to append after a function some
> tests as part of the language
> has benefits imho:
> 
> - the scope is reduced to the function - so it helps making 'real'
> isolated unit tests.

I don't understand this comment. In what way are unit tests from the 
unittest module, or doctests, not "real" unit tests?


-- 
Steven