

Guido's Proposal: Moratorium on Python language changes - sammcd
http://mail.python.org/pipermail/python-ideas/2009-October/006305.html

======
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.)

~~~
andreyf
_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>

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_.

~~~
btilly
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/Filt...](http://search.cpan.org/~smueller/Filter-
Simple-0.84/lib/Filter/Simple.pm) 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/Dev...](http://search.cpan.org/~flora/Devel-
Declare-0.005011/lib/Devel/Declare.pm). For an example of how much that can
change the language, look at [http://search.cpan.org/dist/MooseX-
Declare/lib/MooseX/Declar...](http://search.cpan.org/dist/MooseX-
Declare/lib/MooseX/Declare.pm).

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> 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.

~~~
mst
"For example it wasn't until Switch.pm was pulled into the core that it could
be done without source filters."

Not true, actually - it could comfortably be done with Devel::Declare - we
just haven't had time to yet.

(I wrote Devel::Declare and in fact have been trying for about a year to
persuade somebody to write me the smartmatch logic for perl5 v8 with a promise
that I'll do the given/when syntax if somebody does ...)

Source filters fail because they're line-by-line; Devel::Declare is still
effectively a filter in some respects but it's one that co-operates with the
tokenizer so it tends not to interact badly with anything. If you've seen
places it does, failing tests would be very welcome.

~~~
btilly
I stand corrected.

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

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

~~~
amackera
Hate to break it to you, but it's BD _FL_.

------
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.

~~~
monos
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
The GIL is an implementation detail; not a bug.

~~~
amalcon
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.

~~~
ubernostrum
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)

~~~
eru
If your `while'-loops would crash after a certain number of iterations (and
use linear memory before that), would you call that an implementation detail
or a leaky abstraction? I'd call it a bug.

And special case constructs for linear recursion like `for' and `while' are
only a necessary band-aid in languages that do not treat functions properly.

~~~
ubernostrum
Thank you for making my point eloquently.

The assumption that the way you prefer to write code should be the only way to
write code is, well, exactly what I was talking about.

------
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?

~~~
jacobolus
He did talk about it in his keynote at the 2009 PyCon.

Summary: [http://pypap.blogspot.com/2009/06/pycon-2009-notes-
march-28t...](http://pypap.blogspot.com/2009/06/pycon-2009-notes-
march-28th.html)

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.”_

------
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 :)

~~~
reggieband
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.

------
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.

~~~
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.

~~~
costan
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.)

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

~~~
lispm
Common Lisp has a moratorium on language changes since 1994.

~~~
PieSquared
Now, if only Common Lisp declared an anti-moratorium and decided to make some
language changes, maybe it would become decently relevant.

~~~
eru
Perhaps. Though (PLT) Scheme seems (to me) the better basis for any work on
Lisp nowadays. Common Lisp is just too ugly.

~~~
PieSquared
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?)

~~~
eru
See <http://docs.plt-scheme.org/mzlib/mzlib_defmacro.html>

(And I would not want to do loop in Scheme. That's just too imperative.
Interestingly Haskell's special syntax for Monads and its lazyness makes the
need for most macros / special forms go away (though not for all, and Haskell
has plenty of syntax on the surface).)

Consider that Paul Graham, the author of the fine book "On Lisp", chose PLT
Scheme to implement Arc on top.

~~~
garnet7
IIRC, they didn't choose PLT (over other Schemes) for any particularly
compelling reasons.

------
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.

~~~
swannodette
Features do not a language make. I believe design to be at the core of PL
innovation.

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

