[Python-ideas] Syntax: 'return: ...' expressions

[Nick Coghlan]

On 9 January 2015 at 18:46, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Thursday, January 8, 2015 11:35 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>
>
>> The statement/expression distinction is deliberate, for the reasons
>> you describe in the final article of your post. You will have zero
>> chance of persuading anyone if you start from an assumption that the
>> distinction is accidental.
>
> It strikes me that it might be useful if there were some good official explanation of this (maybe in the Design & History FAQ).
>
> Many other "modern" languages (Ruby, CoffeeScript, etc.) try to eliminate or hide the distinction as much as possible. And JavaScript documentation often apologizes for having the distinction and explains how you can "work around the problem" by defining and calling a function inline to wrap any statement. So, many people believe that the distinction is all negatives with no positives.
>
> I believe the distinction isn't just there to keep the parser simpler, or because Guido wasn't clever enough to figure out how to embed statements in expressions in an indentation-significant language, or because the examples of Ruby and CoffeeScript didn't exist yet and now it's too late for Python; statements are a big part of what makes Python code more readable than those languages, both in-depth and in a quick scan to see the general flow control and state changes.
>
> But it's hard to explain why. And, even if I manage to explain why _I_ think statements make Python more readable, that's just my opinion; it would be nice to have something that Guido endorsed.
>
> Also, for people who want to suggest changes to Python (or design their own languages), it would be helpful to understand how the distinction fits in with other things. For example, in a pure functional language, there may be no benefit to having statements. In a language where (almost) everything is an expression, having mutating methods return self instead of None wouldn't be nearly as much of a problem. More generally, expression-ness and not-mutating are deeply connected (e.g., comprehensions aren't designed for mutation, loop statements are), but it's not easy to say how. And so on.

For myself, the analogy I try drawing these days is to suggest to
people that they look at a cookbook written in English, and then try
translating that cookbook into their preferred programming language in
such a way that anyone who could read the original English version
could still read the translated version without needing to be told
"Oh, don't worry about that bit, it's just needed so the computer
understands what is going on").

When a problem is amenable to being handled in that style, you're
often best off coding it in that style, as that opens up future
maintenance to the broadest possible base of contributors. Languages
that support coding in this style are the ones typically referred to
as "scripting languages", and Python is one of those languages.

However, there are additional styles of thinking that folks can be
trained in (like lambda calculus, object oriented programming, event
driven programming, etc) and the reason those styles of thinking were
created is because the cookbook style starts to encounter scalability
problems when trying to handle higher levels of complexity.

Many programming languages are written on the assumption that a single
style of thinking should be applied to the entire problem space of an
application, and then get referred to by the style of thinking they
promote (so functional programming languages, object-oriented
programming languages, logical assertion languages, etc). This
generally limits the applicability of those languages outside the
problem domains where that particular style of thinking is suitable,
and also means their barriers to entry are much higher than those of
the scripting languages (since you need to learn a new way of thinking
first, whereas scripting languages often let you talk to the computer
using the same kind of reasoning that you'd use to give detailed
step-by-step instructions to another human).

The design of Python takes a more pragmatic approach and recognises
that different problems and situations are best handled through
different kinds of thinking, and so it offers those features as
optional add-ons to the cookbook approach, allowing people to use them
if they make sense in their particular case, *without* making them the
dominant mode of operation of the overall language.

Where folks run into trouble with Python (especially when it comes to
the design side of things) is in trying to ignore that overarching
cookbook element, and *just* use one of the other styles of thinking.
It's not designed to work that way - the "cookbook" layer defines the
overall structure, and then the other aspects like the object-oriented
programming support, the functional programming support and the event
driven programming support all reside within that as suitable tools
for building *components* of larger systems.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia