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

[Josiah Carlson]

On Fri, Sep 12, 2008 at 8:55 AM, Cliff Wells <cliff at develix.com> wrote:
> 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.

The growth limiting mechanism is doomed to failure, or the 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.

It would seem that you are saying that limiting Python's complexity is
a bad thing.  Please correct me if my understanding of your statement
is incorrect.

I'm personally of the opinion that limiting the complexity of Python
as a language is a good thing.  And so far, I think Guido has done a
fairly very good job at keeping Python moving in a positive direction.

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

If the rate of language feature growth is slowed by Guido, then
obviously the growth of Python's core language is limited.  I would
argue that this is a good thing, as the more language syntax and
features that are present, the steeper the learning curve for new
users of the language.

Python 2.5.2 is a wholly different beast from the Python 1.5.2 that I
started with, but I've had nearly 10 years to update my understanding
of the language.  For new users?  Metaclasses, list comprehensions,
generator expressions, generators, ... I get asked about them all.
And the language keeps growing!

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

But not all.  Why?  Because not all proposed extensions to Python are
worth discussing outside of a water-cooler "wouldn't it be neat if?"
discussion.  See the proposed extension to list comprehensions where
"order by" was proposed from sql (a year or two ago at this point).
That shouldn't have even made it to python-dev.  Yet it did.  Why?
Because everyone has their "I really want X", and too few people are
willing to acknowledge that they can be wrong.

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

Python 3.0 is one of the ways that features are shed.  While Guido has
stated that he doesn't believe that there will be a Python 4k (aka
Python 4.0) that hits the reset button again, I think that there needs
to be one, so that Python *can* get rid of bad features that we were
wrong about.  There's also the PEP process, which as long as there
isn't sweeping "break everything" changes, it would seem that we can
remove features as time goes on.

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

...To a functional programming paradigm.  That's what you meant to say, right?

> 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 don't agree.