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

[Cliff Wells]

On Fri, 2008-09-12 at 11:00 -0400, Mike Meyer wrote:
> On Thu, 11 Sep 2008 18:01:55 -0700
> Cliff Wells <cliff at develix.com> wrote:
> 
> > On Thu, 2008-09-11 at 15:14 -0700, Bruce Leban wrote:
> > > I agree that making every statement also an expression has merits, as
> > > does FP. However, you're handwaving about how this fits into python.
> > 
> > Sure.  I intentionally handwave for two reasons:
> > 
> > 1) it's a bit of a waste of time to detail something like this when it's
> > universally rejected
> > 2) I didn't want to bicker over details.  I wanted to forward the
> > concept.
> 
> Ah, I get it. I thought you knew something about the Python user
> community. Clearly, that's not the case. 

I'll concede I more-or-less stopped reading c.l.py at least 3 or 4 years
ago ;-)  

> If you look through the
> proposed changes to python, you'll find this kind of thing (changes
> that introduce a single powerful feature that let you manipulate
> statements in expressions) surfacing at regular intervals over at
> least the past 15 years. The idea is almost never rejected
> outright. In fact, if you look, that's what's happening here - people
> aren't rejecting your position outright, but trying to get enough
> information to figure out how it's going to affect the entire
> language.

Yes, I accept the responsibility for conflating what I see as a problem
with a possible solution to that problem (the two were inextricably
linked in my mind).

> That's another place where the Python community differs from other
> language communities. We don't believe in features for the sake of
> features (whether you get them by adding or removing things); we
> believe the features in the language should interact well with each
> other. So while some feature may scratch a particular itch - say to do
> FP programming in Python - the fact that it turns ugly when used in
> non-FP code, or requires ignoring fundamental language layout rules,
> are not things that tie one hand behind your back, but crucial
> problems that must be solved if the feature is to be added. So even
> though the idea behind a feature may be generally acceptable - and
> that seems to be the case here - it won't be adopted until those
> details get worked out.

Agreed, and I had intended to move to that stage once I felt there was a
consensus that there is actually something that needs solving.  What I
failed to make clear in my position is that I'm not trying to add a
feature for a it's own sake, rather that the current process for
limiting the growth of the Python language is doomed to failure.  

I'm going to try to rephrase the fundamental problem I see here and
hopefully I won't fail so dismally this time:

1) I assert that small is better than large when it comes to limiting
complexity.

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.

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. 

4) As Python moves into new domains, as new programming languages come
into vogue, and as the art of programming itself advances (albeit
glacially), users will perceive needs in Python and will clamor for
extensions.  Some of these will eventually be accepted.

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).

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.

* See the ternary if-operator for an example - steadily rejected by GvR
for many years and then finally accepted, probably out of exhaustion.


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.   

If we agree that the issues I outline above are valid, then I think we
can start bickering over possible solutions and how those solutions
would affect Python on the whole.

I apologize for my previous response to you.  It was clearly my own
failing to properly explain my position that led to our exchange.

Regards,
Cliff