On Fri, 2008-09-12 at 14:03 -0400, Mike Meyer wrote:

On Fri, 12 Sep 2008 08:55:51 -0700 Cliff Wells cliff@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