John Roth wrote: > "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.
Could you give examples of some of what 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 I don't see the connection between the linked article and this discussion. Not having methods for doing things that have equivalent, simple implementations does not make Python left behind. > 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. You don't *have* to follow the convention, but it makes it much easier for other programmers to read your code. > 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. A GUI is not a critical part of a programming language. You only need a GUI for end users. Not all programmers make programs for end users. > 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. Map and filter are not special. Why have two ways to do the same thing? Reduce is a special case, but the arguments against map and filter are quite sensible. > > 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. More people does not mean better. > 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. Take another look then. -Devan L -- http://mail.python.org/mailman/listinfo/python-list
