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

[Cliff Wells]

On Fri, 2008-09-12 at 09:51 -0700, Josiah Carlson wrote:
> On Fri, Sep 12, 2008 at 8:55 AM, Cliff Wells <cliff at develix.com> wrote:

> > 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 asserting that the limiting mechanism 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.

No, I'm saying limiting complexity is good and that smaller is better.

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

Yes, but I also feel that the language has already grown to a point
where only a shrinking subset of Python users fully know and understand
the full feature set.  For people who have been using Python for many
years, they've possibly had time to digest the new features.  I don't
believe new users fare as well.

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

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.

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

Absolutely.  But this isn't what Python has been doing (as you
acknowledge below).  We seem to be agreeing on this point, so I believe
our disagreement must center around whether the current process
continues to be sufficient.

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

I switched from C to Python right as 1.5.1 was being phased out.  To
this day I continue to use a subset of Python that is probably much
closer to 1.5.x than 2.5.   This may be attributed to a personal failing
(my self-professed laziness), but the fact remains that I prefer a
small, versatile set of constructs to a large set of specialized ones. 

C, for all of its shortcomings, had one absolutely compelling feature:
you could keep the entire language in your head and you could do it in
an amazingly short time.  Python 1.5 was similar in scope.  2.5 is
arguably at or beyond that limit for most people.

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

Right, but I am suggesting that perhaps at least some of this problem
(the need users feel for extensions) is currently built into the
language.  I also made this point to bolster my argument that
feature-creep is inevitable.

Outside of the object unification that's been happening over the last
few years, most of the features being added to Python appear to be
oriented to supporting the FP paradigm (generators, list comps, ternary
if, etc).  However these features appear to be added in an ad hoc
fashion.  I'm not suggesting they weren't thought out, only that they
were added based on demand rather than as part of an overall plan as the
object unification was.

It appears to me that most of these "water-cooler" suggestions are
proposed precisely because 

a) Users encounter a situation where an elegant solution isn't obvious
and they feel they must resort to magic and hackery.

b) The elegant solution they were looking for is embodied as an
extension or requires knowledge that is more advanced than the problem
at hand would seem to require (e.g. metaclasses).

c) The PEPs (or more commonly, the flamewars on c.l.py) begin.

For example, earlier in this thread you provided an elegant solution to
what appeared (to myself and at least one other person) to be an
intractable problem.  But of course, it wasn't the natural solution to
most people.  It's ironic, because I've actually used a similar solution
before, but wasn't able to see it this time.  In fact, every time I have
to use it, I have to reinvent it because it isn't the natural way the
problem is expressed.  The problem is most naturally expressed
procedurally but must be solved with an OO paradigm.  

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

Sure, and I think this is a valuable process.  

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

Yes, although by "to" I would mean "allow for" rather than "convert to".
In other words, not convert to or even encourage the FP paradigm, but
also not prevent it.  It would be embracing multi-paradigm approaches
rather than abandoning one in favor of another.  Python has always been
multi-paradigm to an extent (procedural and object), but has always been
somewhat adverse to the functional paradigm (aside from a few helpful
things).  

Before Python's object unification efforts, many OO purists declaimed
Python because its hybrid approach.  Pythonistas claimed that they were
wrong because "practicality beats purity", etc.  But of course, we've
all seen that to a large degree they were right.  Practicality might
beat purity, but practicality plus purity trumps both.  

Functional programming is, in fact, simply the logical extension of
procedural programming (or more precisely, procedural is a subset of
functional).  They are in no way mutually exclusive.  Much as Python's
OO was hampered by distinctions between builtin classes and user-defined
classes (amongst other things), so is Python's procedural support
hampered by it's rejection of the functional paradigm.   

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

Well, that's a start. 

Regards,
Cliff