[Python-ideas] Where-statement (Proposal for =?iso-8859-1?q?function=09expressions?=)

[Steven D'Aprano]

On Sat, 18 Jul 2009 02:20:43 pm Greg Ewing wrote:
> > Steven D'Aprano wrote:
> > > In a real sense, the proposed 'where' block breaks the flow of
> > > reading code. Normally, reading a function proceeds in an orderly
> > > fashion from the start of the function to the end in (mostly)
> > > sequential order, a bottom-up process:
>
> Here you're assuming that the order of *execution* of the
> code is necessarily the best order for *reading* it in
> order to understand what it does.
>
> In general I think that's mostly false. When encountering
> a program for the first time, one tends to look for the
> "main" function first, to get an overall idea of what's
> being done, then recursively work one's way down into lower
> level functions.

I was explicitly talking about reading a *function*, not the entire 
program. In general, one does not try to keep the entire program in 
one's brain at once (unless it's a trivial program) -- one swaps 
individual routines in and out as required:

"Hmm, let's see how the main function works... okay, first it grabs 
input from the user, now that I know that, I can pop the details from 
short-term memory and just treat it as a 'get input' black box. Next it 
creates a Pager object, what does that do... oh, it creates pages, duh, 
now I can forget the details and treat it as a black box as well... "

(At least I do this.)

But for understanding a single function, you do need to keep the whole 
thing in your mind at once: you can't treat it as a black box, because 
that defeats the purpose of trying to *understand* it. (If you want a 
black box, just read the doc string and function signature and you're 
done.) That's one of the reasons why giant monolithic functions are so 
difficult to understand, even if all they do is one thing. It's also 
why spaghetti code within a single function is so harmful: it defeats 
the reader's ability to compartmentalise functionality into easily 
understandable chunks.


> Python supports this on a large scale by allowing functions
> and classes to be written pretty much in any order,
> regardless of the order of execution.

Yes, and so it should -- a certain amount of "spaghetti" is unavoidable 
in any non-trivial program, but so long as it's kept under control, 
it's not too bad. But a single function is different.


> There's not much support for it on a small scale, though.
> There is a little. List comprehensions are one example,
> where you get to see the high-level intent first -- make
> a list of stuff -- and then you're shown the lower-level
> details.

That's hardly different from a for loop though.


> Another one that's easy to overlook is the assignment
> statement. Nobody seems to be bothered by the fact that
> the *right* hand side has to be evaluated before assigning
> to the left hand side.

I've often wondered whether coding would be simpler (at least for 
beginners) if we wrote assignment left-to-right like this:

2*x + 1 => y

instead of

y = 2*x + 1

That might be a nice experiment for a teaching language some day: does 
left-to-right assignment reduce or eliminate the confusion that 
beginners experience over assignment?

In fact, the more I think about it, the more I like the idea.

Oh yes... Hypertalk does that, only very verbosely:

put 2*x + 1 into y

And doesn't Cobol do something similar?



> In a sense, the where-block is in part an attempt to extend
> the assignment statement so that the "right hand side" can
> span more than one statement.

Yes, I get that. I understand the rationale for it, I just think it's a 
bad idea.




-- 
Steven D'Aprano