Guido's Proposal: Moratorium on Python language changes

[andreyf]

frequent changes to the language cause pain for implementors of alternate implementations (Jython, IronPython, PyPy, and others probably already in the wings) at little or no benefit to the average user (who won't see the changes for years to come

If this isn't a good reason to leave a language's semantics mutable via compile-time macros, I don't see what is...

[btilly]

There is a lot of value in mutable semantics. However when you go to share code, there is a lot of room for bad interactions between packages as well.

The principle that only one person gets to be clever at a time holds in spades when you start changing semantics and/or syntax.

This problem is lessened quite a bit with a language like Lisp which has a uniform syntax. It is at its worst with a language like Perl with a very non-uniform syntax. (Yes, there actually are several ways in Perl to change the semantics of the language on the fly.) However even with Lisp you can encounter issues, particularly if people are using reader macros. (This is one of the reason that the Lisp community uses reader macros so sparingly.)

[brown9-2]

Given that Guido is the "benevolent dictator", how does this proposal process work - he proposes it, and then he accepts it?

[mst]

I suspect it works how it always does for a BDFL (as I am for DBIx::Class in the perl world) - whoever likes proposes, if I like it I try and argue for it, only if there's a majority in favour does it get accepted anyway.

Except that if there's no consensus decision after a long discussion I get to make the choice. And no matter how any decision was come to, it's my fault if it's wrong.

Guido, Linus, and the various other BDFLs with important projects and actual talent seem to run things much the same way - I can't speak for their approaches but they largely inspired mine so I suspect I'm not completely wrong :)

[algorias]

the "benevolent" part means he won't make any decision based solely on his own preferences, even though he has the authority to.

[japherwocky]

he proposes it, listens to the feedback, and makes his final decision.

[d3vvnull]

I think Guido resigned from the BDFL position a little while ago.

[monos]

  > if someone came up with (otherwise acceptable)
  > changes to get rid of the GIL I wouldn't object.

that was the big news for me.

[jnoller]

Then you're not paying attention. No one (except a broken minority) said that they would not want to get rid of the GIL so long as single threaded performance was note degraded. Guido himself has stated this time and time again. The one thing missing to all the bright ideas and suggested ways of doing it?

A patch.

[varikin]

From what I have read, GvR and other core Python people are in favor of removing the GIL, but the solution to removing the GIL has to not hurt performance CPython and must not cause any regressions. Some have worked on replacing GIL, but have not finished the work.

[maksim73]

GvR talked about retirement for a while, I see this as the official announcement. It's unlikely that in N years when the freeze ends GvR will continue to moderate the discussion on Python evolution.

This could also signal the beginning of python as "the" mainstream language as this makes it a lower risk proposition for vendors to embrace the language.

[ash]

I tried searching around, but found only April Fool announcement of GvR retirement:

http://www.python.org/dev/peps/pep-0401/

Any links to actual talks about retirement?

[amichail]

Is there an implementation that will target the iPhone?

[pgbovine]

google's unladen swallow targets LLVM, and apple is now sponsoring work on LLVM, which they might be using to target iPhone ... so it could become a reality in the near future :)

[jnoller]

As soon as the SDK agreement doesn't ban interpreters, I could see such a thing coming, but not from -core

[igrigorik]

Great way to kill the momentum and innovation. The only reason Ruby is still relevant today is directly due to its dynamism and continuous evolution. If Python declares a moratorium, they'll be shooting themselves in the foot.

[jacobolus]

Basically, this means not adding any new language features for about 2-3 years, instead focusing on making improvements to the standard library, and to performance and correctness of the core. The moratorium sounds like a great idea to me: it will help reassure people who are porting their code from 2.x to 3.1 that they won’t have to make too many more changes to keep their stuff working on 3.2 & 3.3, and other implementations (Jython, IronPython, PyPy(?)) will be able to catch up to 3.x features.

[bendotc]

I disagree. The last thing Python needs right now is to make Python 3.x even more different from the 2.x line. As a strategic move, I think it makes a lot of sense to stabilize 3.x and wait for it to gain momentum before going on to more syntax changes.

Though I have to say, I'm quite disappointed that PEP 380 is getting left behind, since I find the alternative to be pretty ugly and heavy-weight.

[jshen]

ruby is having a very hard time getting people to switch to 1.9

Stability is important to a whole lot of people, but it is a delicate balancing act.

[njharman]

There's more to momentum and innovation than piling on more syntax.

In fact putting restrictions on things (such as you can't add syntax or break backwords compatibility) can engender more innovation than letting people do whatever.

[costan]

Haha, I was just thinking this rocks for Ruby and other upcoming languages. If people don't have new Python features to play with, they can spend the time learning new languages.

I hope the proposal gets accepted, because I don't like python (personal taste, not trying to start a flame war) and I hope it stops showing up in all the systems I work with.

[abalashov]

Great idea! I wish the maintainers & implementors of other languages would follow suit.

[swannodette]

Why?

Doesn't it depend on your goals? For example, I expect Haskell to be a hotbed for experimentation for a long time to come. In fact I think people choose Haskell because it is continuously evolving.

I know that I picked Clojure recently not just because of it's features - I picked it because it _wasn't_ stable, it _wasn't_ all figured out. In fact, as part of the community, you can actually contribute a hand to it's future.

It's just Python has matured to the point where people would rather experiment with it's implementation rather than it's syntax/expressivity. It also has to do with the fact that this looks like part of a growing effort to make Python _immensely_ popular - going head to head with the likes of C++/Java.

As far as I'm concerned that's a good thing for Python.

But it does mean if you're looking for new ideas in PLs you'll have to look elsewhere. But it's not like there's a lack of excellent and popular candidates these days.

[lispm]

Common Lisp has a moratorium on language changes since 1994.

[swannodette]

This is potentially pretty big news. While this means that we'll probably see blazingly fast/cool implementations, Python as a laboratory for language innovation is coming to an end.

[dschobel]

I don't know of a single language feature which python has innovated.

Python is just a beautiful synthesis of idioms and features which had previously only existed in more esoteric languages.

[Estragon]

Oh, YES! This would give me a chance to catch up. :-)