7 ms·

Guido's Proposal: Moratorium on Python language changes

210 points by sammcd 17y ago

andreyf 17y ago
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 17y ago
  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.)
  - andreyf 17y ago
    when you go to share code, there is a lot of room for bad interactions between packages as well There's absolutely no reason for syntax changes to be global. On the contrary, Python already has a way to change syntax locally in a module, through imports from __future__. For example, "x = print" is invalid syntax in Python2.6, unless you include "from __future__ import print_function" at the beginning of the file. It is at its worst with a language like Perl with a very non-uniform syntax. Perl 5 did not have compile-time macros (to my knowledge), so whatever bad rep it got for ugliness isn't coming from those. The compile-time macros in Perl 6 are very clean, IMO: http://en.wikipedia.org/wiki/Perl_6#Macros http://en.wikipedia.org/wiki/Perl_6#Macros Whatever down-side there is to confusing people by creating a local anaphoric aif-s and awhile-s completely dwarfs in comparison to the benefits of not freezing the syntax.
    - tvon 17y ago
      For example, "x = print" is invalid syntax in Python2.6, unless you include "from __future__ import print_function" at the beginning of the file. Well, you're not changing any syntax there. Print moves from a statement in 2.6 to a function in 3.x, and if it's a function you can just assign it like any other function. In other words, after doing "x = print" you still could not call "x 'hello world'", you'd have to use "x('hello world')". (not that I disagree with your overall argument)
      - andreyf 17y ago
        Statements and expressions are different syntactic elements. So "x = print" will throw a syntax error in 2.6: >>> x = print File "<stdin>", line 1 x = print ^ SyntaxError: invalid syntax But not if you "from __future__ import print_function" first. This is also why __future__ imports need to be at the very top of each file they are included in (unlike other imports).
        tvon 17y ago
        Ah yes, apologies, I completely misunderstood your statement.
    - btilly 17y ago
      Actually Perl 5 does have compile-time macros. First you can implement them with source filtering. See http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filter/Simple.pm http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filt... for an example to make that easier. That is how Switch was implemented by Damian Conway before it got pulled into the core. But you can also do them without source filtering using http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Devel/Declare.pm http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Dev.... For an example of how much that can change the language, look at http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declar.... That said, my point about Perl seems to have been unclear. I'm not saying that Perl has a reputation for ugliness because people change the syntax on the fly. I'm saying that layering macros in Perl is problematic because they interact badly with the syntax. This is why wise Perl programmers avoid source filters and modules that use source filters. Experience has shown that they are very fragile, and don't play well together when you start stacking them. (I'm guessing that fragility is one of the reasons why http://search.cpan.org/~elizabeth/ifdef-0.07/lib/ifdef.pm http://search.cpan.org/~elizabeth/ifdef-0.07/lib/ifdef.pm limited itself to stuff embedded in POD.) Unfortunately some things can't be done in Perl without core support or source filters. For example it wasn't until Switch.pm was pulled into the core that it could be done without source filters.
  - jimbokun 17y ago
    "(This is one of the reason that the Lisp community uses reader macros so sparingly.)" And why Rich Hickey chose to reserve reader macros for his own exclusive use (as language designer in chief) in Clojure.
amichail 17y ago
Is there an implementation that will target the iPhone?
- pgbovine 17y ago
  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 :)
  - reggieband 17y ago
    If Adobe can use LLVM to compile Actionscript for the iphone, then it seems very likely work could be done to get Python to compile to the iPhone as well.
  - jey 17y ago
    LLVM does have an ARM target.
- jnoller 17y ago
  As soon as the SDK agreement doesn't ban interpreters, I could see such a thing coming, but not from -core
  - amichail 17y ago
    Here's a compiler: http://code.google.com/p/shedskin http://code.google.com/p/shedskin
    - kingkilr 17y ago
      That's not a compiler for Python. It's a compiler for a limited subset of Python that works via source to source translation targeting C++, you could write a version of it targeting Objective-C if you wanted.
      - DougBTX 17y ago
monos 17y ago
> 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 17y ago
  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.
  - monos 17y ago
    thx for clarifying this. still a strange example since the GIL is not thought to be a problem, from what i read on pydev.
    - jnoller 17y ago
      The GIL is an implementation detail; not a bug.
      - amalcon 17y ago
        Calling the GIL an implementation detail is like calling tail call elimination an implementation detail: for most software, it may be so, but there are idioms one may or may not be able to use depending on that detail. It's a visible implementation detail.
        aceofspades19 17y ago
        Well, in other implementations like jython and iron python, the GIL doesn't exist, so I think most people would consider it just an implementation detail
        ubernostrum 17y ago
        Tail-call is an implementation detail. The fact that some people think it's as fundamental to programming as the Ten Commandments is to the Judeo-Christian tradition is... well, perhaps more a problem with programmers than with language implementations. (and yes, it's visible, and that's one reason why I have issues with it -- it's a classic leaky abstraction, except in this case the "leak" is more like a torrential flood)
brown9-2 17y ago
Given that Guido is the "benevolent dictator", how does this proposal process work - he proposes it, and then he accepts it?
- japherwocky 17y ago
  he proposes it, listens to the feedback, and makes his final decision.
- algorias 17y ago
  the "benevolent" part means he won't make any decision based solely on his own preferences, even though he has the authority to.
  - stcredzero 17y ago
    Lambdas?
- mst 17y ago
  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 :)
- d3vvnull 17y ago
  I think Guido resigned from the BDFL position a little while ago.
  - amackera 17y ago
    Hate to break it to you, but it's BDFL.
  - 17y ago
swannodette 17y ago
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 17y ago
  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.
  - swannodette 17y ago
    Features do not a language make. I believe design to be at the core of PL innovation.
  - amackera 17y ago
    In my mind, the synthesis itself is a language feature.
Estragon 17y ago
Oh, YES! This would give me a chance to catch up. :-)
igrigorik 17y ago
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.
- bendotc 17y ago
  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.
- jacobolus 17y ago
  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.
- jshen 17y ago
  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.
  - costan 17y ago
    That's because Ruby folks don't work on that as a community. We're all working on our pet projects, instead of helping get ruby1.9 into the popular OSes -- there's no one-click installer for Windows or OSX, and packages for various linux distros are lagging. (Yes, I'm pointing the finger at myself too... if only I could stop wasting my time on random stuff, I could spend a bit of time each week helping out.)
- 17y ago
abalashov 17y ago
Great idea! I wish the maintainers & implementors of other languages would follow suit.
- swannodette 17y ago
  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 17y ago
  Common Lisp has a moratorium on language changes since 1994.
  - PieSquared 17y ago
    Now, if only Common Lisp declared an anti-moratorium and decided to make some language changes, maybe it would become decently relevant.
    - eru 17y ago
      Perhaps. Though (PLT) Scheme seems (to me) the better basis for any work on Lisp nowadays. Common Lisp is just too ugly.
      - PieSquared 17y ago
        I can't help love the power of real macros, though. Can you get something like loop to work in Scheme? To me that's just part of the beauty of Common Lisp. While it is rather ugly in some places, it has these nuggets of just pure gold. (I actually do not know scheme well enough to say. Are such complicated macros possible in it?)
maksim73 17y ago
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 17y ago
  I tried searching around, but found only April Fool announcement of GvR retirement: http://www.python.org/dev/peps/pep-0401/ http://www.python.org/dev/peps/pep-0401/ Any links to actual talks about retirement?
  - jacobolus 17y ago
    He did talk about it in his keynote at the 2009 PyCon. Summary: http://pypap.blogspot.com/2009/06/pycon-2009-notes-march-28th.html http://pypap.blogspot.com/2009/06/pycon-2009-notes-march-28t... From there: > “I’m not retiring, but I’m tiring.” > doesn’t enjoy traveling like he used to > “I’m sort of thinking over the next five or > ten years to gradually fade away.” > Hopes in 5 years that the BDFL is not actually > leading the community anymore, more of a figurehead. > “Don’t look to me for guidance for everything.”

210 points by sammcd 17y ago

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 17y ago
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.)
- andreyf 17y ago
  when you go to share code, there is a lot of room for bad interactions between packages as well There's absolutely no reason for syntax changes to be global. On the contrary, Python already has a way to change syntax locally in a module, through imports from __future__. For example, "x = print" is invalid syntax in Python2.6, unless you include "from __future__ import print_function" at the beginning of the file. It is at its worst with a language like Perl with a very non-uniform syntax. Perl 5 did not have compile-time macros (to my knowledge), so whatever bad rep it got for ugliness isn't coming from those. The compile-time macros in Perl 6 are very clean, IMO: http://en.wikipedia.org/wiki/Perl_6#Macros http://en.wikipedia.org/wiki/Perl_6#Macros Whatever down-side there is to confusing people by creating a local anaphoric aif-s and awhile-s completely dwarfs in comparison to the benefits of not freezing the syntax.
  - tvon 17y ago
    For example, "x = print" is invalid syntax in Python2.6, unless you include "from __future__ import print_function" at the beginning of the file. Well, you're not changing any syntax there. Print moves from a statement in 2.6 to a function in 3.x, and if it's a function you can just assign it like any other function. In other words, after doing "x = print" you still could not call "x 'hello world'", you'd have to use "x('hello world')". (not that I disagree with your overall argument)
    - andreyf 17y ago
      Statements and expressions are different syntactic elements. So "x = print" will throw a syntax error in 2.6: >>> x = print File "<stdin>", line 1 x = print ^ SyntaxError: invalid syntax But not if you "from __future__ import print_function" first. This is also why __future__ imports need to be at the very top of each file they are included in (unlike other imports).
      - tvon 17y ago
        Ah yes, apologies, I completely misunderstood your statement.
  - btilly 17y ago
    Actually Perl 5 does have compile-time macros. First you can implement them with source filtering. See http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filter/Simple.pm http://search.cpan.org/~smueller/Filter-Simple-0.84/lib/Filt... for an example to make that easier. That is how Switch was implemented by Damian Conway before it got pulled into the core. But you can also do them without source filtering using http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Devel/Declare.pm http://search.cpan.org/~flora/Devel-Declare-0.005011/lib/Dev.... For an example of how much that can change the language, look at http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declar.... That said, my point about Perl seems to have been unclear. I'm not saying that Perl has a reputation for ugliness because people change the syntax on the fly. I'm saying that layering macros in Perl is problematic because they interact badly with the syntax. This is why wise Perl programmers avoid source filters and modules that use source filters. Experience has shown that they are very fragile, and don't play well together when you start stacking them. (I'm guessing that fragility is one of the reasons why http://search.cpan.org/~elizabeth/ifdef-0.07/lib/ifdef.pm http://search.cpan.org/~elizabeth/ifdef-0.07/lib/ifdef.pm limited itself to stuff embedded in POD.) Unfortunately some things can't be done in Perl without core support or source filters. For example it wasn't until Switch.pm was pulled into the core that it could be done without source filters.
- jimbokun 17y ago
  "(This is one of the reason that the Lisp community uses reader macros so sparingly.)" And why Rich Hickey chose to reserve reader macros for his own exclusive use (as language designer in chief) in Clojure.

amichail 17y ago

Is there an implementation that will target the iPhone?

pgbovine 17y ago
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 :)
- reggieband 17y ago
  If Adobe can use LLVM to compile Actionscript for the iphone, then it seems very likely work could be done to get Python to compile to the iPhone as well.
- jey 17y ago
  LLVM does have an ARM target.
jnoller 17y ago
As soon as the SDK agreement doesn't ban interpreters, I could see such a thing coming, but not from -core
- amichail 17y ago
  Here's a compiler: http://code.google.com/p/shedskin http://code.google.com/p/shedskin
  - kingkilr 17y ago
    That's not a compiler for Python. It's a compiler for a limited subset of Python that works via source to source translation targeting C++, you could write a version of it targeting Objective-C if you wanted.
    - DougBTX 17y ago

monos 17y ago

> 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 17y ago
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.
- monos 17y ago
  thx for clarifying this. still a strange example since the GIL is not thought to be a problem, from what i read on pydev.
  - jnoller 17y ago
    The GIL is an implementation detail; not a bug.
    - amalcon 17y ago
      Calling the GIL an implementation detail is like calling tail call elimination an implementation detail: for most software, it may be so, but there are idioms one may or may not be able to use depending on that detail. It's a visible implementation detail.
      - aceofspades19 17y ago
        Well, in other implementations like jython and iron python, the GIL doesn't exist, so I think most people would consider it just an implementation detail
      - ubernostrum 17y ago
        Tail-call is an implementation detail. The fact that some people think it's as fundamental to programming as the Ten Commandments is to the Judeo-Christian tradition is... well, perhaps more a problem with programmers than with language implementations. (and yes, it's visible, and that's one reason why I have issues with it -- it's a classic leaky abstraction, except in this case the "leak" is more like a torrential flood)

brown9-2 17y ago

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

japherwocky 17y ago
he proposes it, listens to the feedback, and makes his final decision.
algorias 17y ago
the "benevolent" part means he won't make any decision based solely on his own preferences, even though he has the authority to.
- stcredzero 17y ago
  Lambdas?
mst 17y ago
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 :)
d3vvnull 17y ago
I think Guido resigned from the BDFL position a little while ago.
- amackera 17y ago
  Hate to break it to you, but it's BDFL.
- 17y ago

swannodette 17y ago

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 17y ago
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.
- swannodette 17y ago
  Features do not a language make. I believe design to be at the core of PL innovation.
- amackera 17y ago
  In my mind, the synthesis itself is a language feature.

Estragon 17y ago

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

igrigorik 17y ago

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.

bendotc 17y ago
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.
jacobolus 17y ago
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.
jshen 17y ago
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.
- costan 17y ago
  That's because Ruby folks don't work on that as a community. We're all working on our pet projects, instead of helping get ruby1.9 into the popular OSes -- there's no one-click installer for Windows or OSX, and packages for various linux distros are lagging. (Yes, I'm pointing the finger at myself too... if only I could stop wasting my time on random stuff, I could spend a bit of time each week helping out.)
17y ago

abalashov 17y ago

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

swannodette 17y ago
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 17y ago
Common Lisp has a moratorium on language changes since 1994.
- PieSquared 17y ago
  Now, if only Common Lisp declared an anti-moratorium and decided to make some language changes, maybe it would become decently relevant.
  - eru 17y ago
    Perhaps. Though (PLT) Scheme seems (to me) the better basis for any work on Lisp nowadays. Common Lisp is just too ugly.
    - PieSquared 17y ago
      I can't help love the power of real macros, though. Can you get something like loop to work in Scheme? To me that's just part of the beauty of Common Lisp. While it is rather ugly in some places, it has these nuggets of just pure gold. (I actually do not know scheme well enough to say. Are such complicated macros possible in it?)

maksim73 17y ago

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 17y ago
I tried searching around, but found only April Fool announcement of GvR retirement: http://www.python.org/dev/peps/pep-0401/ http://www.python.org/dev/peps/pep-0401/ Any links to actual talks about retirement?
- jacobolus 17y ago
  He did talk about it in his keynote at the 2009 PyCon. Summary: http://pypap.blogspot.com/2009/06/pycon-2009-notes-march-28th.html http://pypap.blogspot.com/2009/06/pycon-2009-notes-march-28t... From there: > “I’m not retiring, but I’m tiring.” > doesn’t enjoy traveling like he used to > “I’m sort of thinking over the next five or > ten years to gradually fade away.” > Hopes in 5 years that the BDFL is not actually > leading the community anymore, more of a figurehead. > “Don’t look to me for guidance for everything.”