[Python-ideas] Statements vs Expressions... why?

[Cliff Wells]

On Fri, 2008-09-12 at 14:24 -0600, Adam Olsen wrote: 
> On Fri, Sep 12, 2008 at 1:29 PM, Cliff Wells <cliff at develix.com> wrote:
> > A slow boat still reaches its destination.  My position is that by
> > obviating the need for a large class of syntax extensions, the onus is
> > moved from the Python core team onto the user desiring a particular
> > extension and by doing so, things like community pressure to add X can
> > be reduced and by extension, the likelihood of the process folding under
> > that pressure becomes much less likely.
> 
> Again, a vast difference in what we consider complexity.

Well there's two forms of complexity to consider: language complexity
and user-program complexity.  A language that's too simple (e.g.
assembler or C) can lead to an explosion of complexity when actually
used to develop a non-trivial program.  

I'd actually agree that language features help reduce program
complexity.  For instance even the simple case of Python lacking the
equivalent of repeat..until or do..while loop forces a tiny bit of
complexity (in the form of a couple extra lines of code and usually an
extra exit point from a loop) into a user's programs.

The complexity I'm referring to is the fact that Python's collection of
statements are rapidly forking into two forms: the original statement
form, and newer expression forms.   Worse, in some cases these
expression forms exist in several sub-forms (e.g. list comps, expression
comps, generators, etc).   These forms all have a single common
*logical* operation in mind (looping), but mutate into other forms
because they are too specialized.  It's also worth noting that most of
them use an inverted syntax from the original statement in order to help
distinguish them.  
I'm claiming that a single more flexible construct could potentially be
used in place of all of them (for-expression with yield), and further,
I'm claiming this is a case where simplifying the language would not
complicate the user's program and in many cases might help to simplify
it.

> For a user, does it matter that we use "len(foo)" rather than "len
> foo"?  A little bit, but it's not huge.

Or more consistently foo.len() which we *almost* have except it's
spelled __len__ :P   I agree this is a minor nit, but also rather
pointless as far as I can tell.

> For the language developers, does it matter?  Again, it's a small
> benefit.  It's still our job to design it, not a third-party.  Syntax
> and stdlib are both part of the language.
> 
> All the things you think we might avoid by being more "functional",
> we'd still have to do them, saving nothing.  Except all the details
> suggest *worse* solutions would be found, as we wouldn't be
> fine-tuning the syntax for the use-cases.
> 
> The only genuine use-case for your changes I've seen in this whole
> thread is the dispatch-dict, but your changes are far too distract to
> justify it.

I'm not surprised.  In fact, after programming in Python myself for a
decade or so I'm surprised I was able to find any suitable example ;-)
The Sapir-Whorf hypotheses predicts this.  A Lisp or Haskell programmer
would probably be much better armed than I to provide concrete examples.
Even if you don't subscribe to Sapir-Whorf, I think you could probably
agree that at least the lack of idioms for FP in Python would contribute
to our mutual inability to visualize particularly useful examples. 

> As an aside, I can't speak for Guido, but I haven't seen any
> indication python's development process may collapse.  It's a
> non-problem.

I didn't mean the development process may collapse, I mean the rejection
process may collapse due to pressure (and I believe it has already on
occasion).

Regards,
Cliff