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

[Cliff Wells]

On Fri, 2008-09-12 at 14:03 -0400, Mike Meyer wrote:
> On Fri, 12 Sep 2008 08:55:51 -0700
> Cliff Wells <cliff at develix.com> wrote:

> > 2) The primary method of limiting Python's core feature growth is for
> > the BDFL to dig in his heels and reject ideas until they are adequately
> > shown to be broadly needed and implementable.
> 
> I don't think you have accurately described things, but it's
> irrelevant because changing this doesn't change the nature of the
> problem.

It may be grossly oversimplified, but I think ultimately the process
ends this way. 

> > 3) This method has failed in the past*.  In fact, I assert that this
> > method is guaranteed to fail unless all ideas that add syntactical
> > structures are rejected outright, regardless of their utility.  It
> > cannot limit the growth of Python's core, it can only limit the rate at
> > which it grows. 
> 
> I think you're using "fail" in two different contexts here; one for an
> individual case - in that something was added - and one in the global
> case - in that the language will continue to grow without bounds.

I'm claiming that the global case is an inevitable conclusion of
repeatedly catering to the individual case. 

> We'll leave aside the first version - whether some particular feature
> was a failure or not is really a question of personal taste, and
> changeable - and look at the latter.
> 
> You're right, they can only limit the growth rate. I contend that that
> isn't a failure - at least not until the language starts losing users
> because the feature count has gotten too large. Based on the success
> of languages where features are treated as valuable just by being
> features, we're still a very long way from that point.

I won't disagree that Python is still a long way from that point.  I
also want absolutely to distance myself from any claim that Python will
one day become obsolete or even lose a single user because of this.
First of all because it's flamebait and secondly because I don't believe
it to be true.   

What I will claim is that the growing the language in such a way is not
doing a favor to its users (even if they might think so for their
particular extension).  I don't think any of us disagree with that.  
Of course it's mildly ironic that I'm being told the same thing about my
proposal, but what I am trying to convey is that it's my belief that my
one modification helps eliminate the need for dozens of others.

> > 5) Given the added desire to maintain backwards-compatibility, old
> > features will not be shed as fast as new ones are added (unless that
> > becomes part of the process, which doesn't seem practicable to me).
> 
> This has already become part of the process. Python 3.0 can break
> backwards compatibility, and so is shedding features - or at least
> moving them out of the core. For instance, the builtin functions that
> are now subsumed into list comprehensions are gone. It was originally
> scheduled for release late this month, but it looks like the schedule
> has slipped a couple of weeks.

Yes, but we want to keep watershed instances like these to an absolute
minimum.  I think removing the redundant (and less flexible) variations
that listcomp now subsumes is a good thing.  What I'm saying is "let's
do it again".  Except what would be subsumed isn't just a handful of
functions, but rather a whole class of existing and future language
extensions.

> > 6) I believe that a large class of these features could be rendered moot
> > or redundant if the language embraced a more sweeping and fundamental
> > change.  While this won't absolutely prevent the language's growth, it
> > provides a built-in deterrent.
> 
> This may well be true. But the absolutely critical issue is that it
> not break the fundamental nature of language. I.e. - if you have to
> add delimters to replace indentation, you ain't going anywhere.

Absolutely, which is why I've never proposed it.  It would fundamentally
alter the visual appearance of the language and ultimately isn't
necessary anyway.

> > There's an old quote by Larry Wall: "Perl is ugly because people wanted
> > it that way".  Perl took the same approach to limiting features that
> > Python does, with the notable difference that Larry didn't reject ideas
> > as consistently as Guido (or apparently at all).  Nevertheless, we're
> > now simply discussing the *rate* at which the language becomes large and
> > inconsistent rather than whether it will or not.   
> 
> LW used to sign books with the note "There's more than one way to do
> it". As far as I can tell, the Perl community never met a feature it
> didn't like, and they're all in Perl5 - and Perl6 is going to make CL
> look small.
> 
> But you just slipped in a new word that you haven't used before -
> "inconsistent".  Becoming large does not necessarily make things
> inconsistent. Most of the features added to Python don't make it
> inconsistent. Actually, the nastiest problems with some of them are
> *because* they are consistent with the rest of the language(*).

True, I was thinking more of Perl when that word popped out of my
keyboard.  

However, I think that there is a fundamental *logical* inconsistency in
Python.  The language consistently adheres to this inconsistency =) but
it's there nonetheless.  This was my motivation for attempting to
demonstrate that the two forms of "if" currently in Python (statement
and operator) could be logically combined into one if the restrictions
on the former were lifted (see below).

> Maintaining consistency is far more important than limiting size, and
> is why most proposals are rejected. I don't feel that any of the
> recent changes have introduced inconsistencies in the language.

Ah, but I do:

if cond: block

vs

expr if cond

Here we have two forms of the *very same* logical construction.  A
programmer must select one or the other based on *context*. This is my
definition of inconsistent (although it's roots lie in a deeper
inconsistency, namely the distinction between expressions and
statements).


Regards,
Cliff