

Python language moratorium is accepted - mcantelon
http://python.org/dev/peps/pep-3003/

======
cool-RR
I hope very much that the freed up cycles will be used to improve Python's
packaging/distribution mechanism, which I think is the weakest link in the
chain of using Python.

~~~
sandGorgon
seconded. Ruby's gem might not be perfect, but it is much more _intuitive_
than anything python has (no idea about "pip" though)

~~~
jacobolus
What's unintuitive about easy_install, in your opinion? In general, all I have
to do to install a Python package is:

$ easy_install «package name»

~~~
arkx
And that's about all it does. You have to update packages manually and you
can't remove them at all with easy_install. What's so beautiful about gem to
me as a Python dev is this:

$ gem update && gem cleanup

A lot of headache I don't have to deal with at all. I really wish Python would
grow an equivalent tool.

------
jparise
It's important to note that improvements to the standard library and C API are
still permitted while the language (grammar) moratorium is in effect.

------
unohoo
great move. Most of hosts I use still are at 2.5 / 2.6 levels. This moratorium
will indeed give time to catch up. Probably I missed it - but does the
moratorium apply to bugs/security patches as well ?

~~~
wtallis
Fundamental language bugs (ambiguity, etc.) can be fixed. Security bugs will
almost certainly be the result of something in the standard library, which has
not been frozen.

~~~
unohoo
cool - thanks. good to know.

------
dschobel
Any word whether PEP 380 ("yield from") made it in before the cut-off?

~~~
jnoller
It did not. PEP 380 will not see the light of day until the moratorium is
lifted. This made me sad while I was writing it, but it is what it is.

~~~
fizx
[http://www.urbandictionary.com/define.php?term=it+is+what+it...](http://www.urbandictionary.com/define.php?term=it+is+what+it+is)

> Used often in the business world, this incredibly versatile phrase can be
> literally translated as "fuck it."

Edit: tongue-in-cheek

~~~
jnoller
Well; that's not what I meant when I said it. I would love to see PEP 380 in,
but I think that the possible benefits of this moratorium outweigh the
usefulness of a new feature only a relatively small populace of users will use
over the next two years.

Remember, well above 90% of the users out there are still on 2.4 and 2.5 -
even if pep 380 went in, it would more than likely be in 3k only (a few years
from widespread adoption anyway) and in a release OS vendors won't ship for a
few years.

~~~
arkx
Are there some sort of studies or statistics out there regarding adoption of
different versions? I'd be interested to see them.

------
jacquesm
I wonder how much it was ever in doubt that this would happen, when a
'benevolent dictator for life' wants something it happens.

From the introduction of the subject on the mailing list it seemed as though
the moratorium was already in place at the time of the announcement.

------
viraptor
After reading the PEP I'm still not sure: does it mean that no changes will be
made at all, or are "from __future__ import ..." additions allowed (but won't
be integrated until 3.3)? [Not allowed - now I see it, my bad]

~~~
jnoller
__future__ additions are banned under this. See "cannot change" point 4

------
Shana
Smart move...Also allows people time to learn the language, and then move into
3 gradually... Go Python People...

------
tptacek
I wish Ruby would make the same promise. I'm kind of bitter about 1.9.

~~~
telemachos
That surprises me. I've been learning Ruby recently (only really working with
1.9), but every time I learn about something that's new or different in 1.9
compared with earlier versions, the new version seems better, cleaner to me
(e.g. 'hello'[1] # => 'h' not 101, Enumerators and MiniTest::Unit, off the top
of my head).

Also, it's significantly faster, no?

~~~
tptacek
Most of 1.9 is indeed "better", but getting to "better" breaks a lot of code.

~~~
protomyth
Wasn't that stated in the 1.9 -> 2.0 plan? I seem to remember that code would
be broken by the 2.0 language.

------
cookiecaper
I actually really think the Linux kernel would benefit from something like
this too; it doesn't have to be a freeze for two years, but dedicating maybe
every third release to strictly bugfixes and performance and stability
improvements and no new features, or something like that, would do a lot of
good, imo. Tightening sessions like that where Linux devs ask everyone to
pitch in to tightening and accept no major feature additions or alterations
would go a long to making things cleaner and faster, and maturing patches
before they are merged (because the skipped cycle would allow extra
improvement on features before the next merge window).

------
TwoBit
Just two years? I suggest six years.

------
jrockway
This will give Perl and Ruby a good chance to pull even farther ahead of
Python. It would be nice if "we" didn't learn anything about programming that
needs new language features, but we do, and it's silly to omit features that
make programming easier.

Oh yeah, it's Python.

~~~
axod
Language wars are so pointless. Spend your energy on something else.

Guess what. The programming language you use is pretty irrelevant to success.
It's a matter of taste, what other people are using (If you care), what has
convenient libraries for what you're doing.

edit: OK I'll bite:

>> "It would be nice if "we" didn't learn anything about programming that
needs new language features, but we do, and it's silly to omit features that
make programming easier."

Examples? What have we _really_ learnt about programming say in the last 5
years that requires new language features? Maybe it's just individuals that
learn things about programming, and change their tastes.

~~~
protomyth
"Language wars are so pointless. Spend your energy on something else."

I think flamewars on languages are painful and wrong, but not pointless.
Programming Languages are how we frame our thoughts about problem solving, and
I think too many people go with the theory any language is ok.

I hope for the sake of language design that the last 5 years would teach us a
lot. Heck, for starters how many languages really have a good story about the
multi-processor hardware that comes standard these days. I think leaving that
solution to libraries really hasn't served us well.

~~~
axod
Programming languages shouldn't be concerned about multi-cores IMHO. That
should be some magic sauce that goes on without anyone knowing/caring. (Also,
5 years ago people were hyping it up saying we'll all have 20 CPUs. Most still
have 2 at most. The need for CPU power on desktops is going down).

Would Charles Dickens stories been any less had he written them in French
rather than English? :/

~~~
protomyth
Well, all programming is not done on a client and poorly using the many CPUs
of a server is not cost effective. I think we are a long way off from the
"magic sauce" and languages designed to allow programmers to express their
programs in a parallel manner are going to have an advantage.

"Would Charles Dickens stories been any less had he written them in French
rather than English? :/" - yep, they would have been - a particular turn of
phrase or expression doesn't always translate well. Different languages bring
different world views.

