"Peter Hansen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > John Roth wrote: >> It's not going to happen because the Python community is fat and happy, >> and is not seeing the competition moving up on the outside. >> Characteristics >> that make a great language one day make a mediocre one a few years >> later, and make a has-been a few years after that. > > And here I thought that was the point of Python 3000. To let the > community produce a much improved language while avoiding the problems > caused by too much change occurring while people are trying to get useful > things done with what the language is _now_. The competition (and let's > see a description of just what that means, too) probably has the dual > advantage of newness and a small, hackerish community that is more than > happy to see rapid and radical change. You're right -- as with the > stereotypical large/slow vs. small/agile company motif -- that smaller and > more agile will pass larger and slow "on the outside", but you're wrong if > you think that means the larger-slower entity should drop what it's been > doing so well and try to compete entirely on the smaller-faster entity's > own ground.
Maybe "fat and happy" wasn't the best choice of words (and maybe Extreme Programming wasn't Kent Beck's best choice of words either.) However. I see nothing in the existing Python 3000 PEP that does anything other than inspire a yawn. Sure, it's a bunch of cleanup, and some of it is definitely needed. What I don't see is the inspired leap forward that will once again put Python in the forefront rather than simply being one choice among many. What I want to see in Python 3000 is an AST based language that lets the editors do the pretty printing. Do you want automatic indenting or would you prefer end statements? It's an editor formatting option. The AST neither knows or cares. Don't want to see self? Editor formatting option. The AST knows what scope each identifier belongs to because it's right there in the text. No need for rules that you have to learn, sometimes the hard way. Want to see type inference? I haven't a clue how to do it in a dynamic language like Python, but an AST based language is a perfect test bed for experimentation. What's good about other languages? I see very little here that is an examination of what Smalltalk, Ruby, Perl, etc. seem to have gotten right and could be moved into Python to good effect. Talk to people who've moved from Python to Ruby, or to some other language. Ask them why, if Python is so great, what's even greater in that other language. If you still don't understand, you might want to read this: http://martinfowler.com/bliki/CollectionClosureMethod.html Look at Pep 8. It's a compendium of coding standards for the standard library. So far, ok. Coding standards are generally good. But why does Guido like underscores in method names? I know there was (and the accent is on the word was) some research, refuted well over a decade ago, that mixedCase was hard to read. The fact is that _all_ conventions for separating words are hard to read until the brain grows new synapses that handle it. Of the options, no separation is the hardest to handle. There are reasons why ancient texts, which had neither word separators nor punctuation, have very contentious translations. I find the notion that there should be one obviously right way to do something to be a good design principle, so why isn't there a single supported GUI library? If I'm over in Java-land, just about everything comes with a GUI. Python ships with a lot of little demonstration and utility scripts - none of which has a GUI. Part of the tone here is because of the PEP 208 voting process. From day one, I knew it was going to fail. Anyone who stood back and looked at the process, rather than getting into the detail, knew it was going to fail. There was no way that the Python community was going to come up with a simple majority in favor of one proposal. None. And it was obvious from the start. And the sad fact is that a proposition of the form: "We want a conditional expression; Guido should pick the syntax he finds the least obnoxious and get on with it" would have passed. Overwhelmingly. I came across a better voting process (Condorcet) later. Unfortunately it was later or I would have suggested it. Why the jihad (and I'm using the word advisedly) against the map, filter and reduce operators? It seems to be completely irrational from my viewpoint. I've seen the arguements, and they make no sense. > BTW, I think "large and stable" would have been less offensive than "fat > and happy", but perhaps you meant to imply we're both lazy and complacent, > rather than just satisfied with something that works and not inclined to > shoot for moving targets every working day. If so, I'm not sure why you'd > say that, since the evidence doesn't support it. I'm not suggesting shooting at a moving target. I'm suggesting getting the head out of the sand, looking at trends, and figuring out the _large_ steps to take next, not the nickle and dime fixups that are the only things I see in PEP 3000. (Not to say that some of them aren't going to be a lot of work. Some of them are.) I came back from Agile2005 last week. The open space session on Ruby was maybe 5 times as large as the one on Python. And both of them were kind of an afterthought. Look at the OSCon blogs. There were a number of hardcore Python people there. They couldn't get into Ruby sessions because they were jammed. Standing room only. There's a report out that the "scripting languages" in general are losing mindshare big time in Europe, Africa and the east in general. In fact, everywhere except in North America. I'm generally somewhat skeptical of these reports unless I can see the methodology, but it's definitely a data point. Another thing that stands out: the explicit versus dynamic typing debate has moved on from program correctness (which is a wash) to other areas that explicit (or derived) type information can be used for. I see this in PyFit: the languages where explicit type information is available by reflection have cleaner implementations. The languages with dynamic typing all have to deal with the fact that they can't get type information by reflection, and it's a diverse mess. The world is moving on, in ways that I think you're not seeing. And Python is standing still in many of those same ways. John Roth John Roth > > > -Peter -- http://mail.python.org/mailman/listinfo/python-list