

Python 2.7 released - cool-RR
http://www.python.org/download/releases/2.7

======
uggedal
The obligatory What's New in Python 2.7 document:
<http://docs.python.org/dev/whatsnew/2.7.html>

~~~
jvdh
Link is broken now, should be: <http://docs.python.org/whatsnew/2.7.html>

(Which is actually from the future! "Python 2.7 was released on July 7,
2010.")

------
j_baker
I'm disappointed that distutils2 didn't make it in this release. Does that
mean it won't be in the standard library until the 3.x series?

~~~
jnoller
It simply was not going to be ready - and with the amount of churn and changes
going on in that space, it was felt that the community would be better served
with something stable, later (but still install-able via pip/etc) then
something unstable and still cooking.

------
tomazmuraus
Great, now we finally have long awaited ordered dictionary in 2.x branch as
well :)

~~~
inferno0069
Unfortunately they have non-transitive equality when used with standard
dictionaries. For example, if O and R are ordered dictionaries with the same
entries in different orders, and D is a standard dictionary with the same
entries, then O == D == R but O != R.

------
simonista
I'm confused by why the python 2.x branch is still being actively developed
with new features rather than just being maintained for bug fixes. What are
the roadmaps and goals of the 2.x verses the 3.x branches?

~~~
xi
2.7 is the last major release of the 2.x series. The goal was to ease
transition to 3.x by backporting some of the features and provide a stable
base for people unable or unwilling to jump to 3.x.

------
AaronMT
How does one go about updating Python on OSX Snow Leopard?

~~~
telemachos
I wouldn't recommend overwriting OSX's Python. You can install yourself from
source into /usr/local, but a package manager like MacPorts or Homebrew helps
a lot. It's a little more work up front - to install the package manager - but
it pays itself back over time. Homebrew has 2.6.5 in its main branch, and 2.7
in a fork. See the notes here:

[http://github.com/mxcl/homebrew/blob/master/Library/Formula/...](http://github.com/mxcl/homebrew/blob/master/Library/Formula/python.rb)

I've tried Fink, MacPorts, Rudix and Homebrew. Homebrew isn't perfect, but
it's damn good.

~~~
jdbeast00
i am a new mac user (and new to *nix in general). i was trying to get mapnik
with postgres working on my mac yesterday and it took me 5 hours to get
macports / mapnik setup, and after most of my day was done it turns out that
ImageMagick via macports and snow leopard don't mix. (Finally I tried
downloading the binary for ImageMagick but then macports doesn't recognize
it..) Very frustrating. Is there really nothing better, or am i just too much
of a noob? What is the reason for making me build it instead of doing
soemthing like apt-get on ubuntu?

~~~
ant5
_What is the reason for making me build it instead of doing soemthing like
apt-get on ubuntu?_

Originally, because around '00 Apple asked some Debian people if they minded
if Apple used dpkg, and GPL non-withstanding, Debian said (paraphrasing): No,
you evil capitalist pigs.

Or at least that's how I remember it being related to me at the time when it
was explained why, in the interest of open-source peace and PR, we couldn't
using dpkg =)

But now, realistically? Because nobody invests the time in doing it. MacPorts
can actually spit out dpkgs, rpms, and apt-get and yum repositories, but
nobody has brought the rest of the glue together to actually build and
distribute binaries using it.

~~~
rdtsc
> Debian said (paraphrasing): No, you evil capitalist pigs.

Oh, please... Apple could have used dpkg if they wanted to.

dpkg is open source software released under the GPL license. Apple just chose
not to, because they would have had to open source all their code that linked
to dpkg libraries.

That is the price they would have to pay for piggy-backing on the efforts of
many volunteers and gain immediate access to a state of the art packaging
system.

But of course Apple being Apple has a lot more money to spend on PR and along
with the help of their fan boys, the story turned into "Debian developers are
mean, capitalism-hating hippies". I am not really surprised.

~~~
ant5
> Oh, please... Apple could have used dpkg if they wanted to.

Apple chose not to given the apparent community stance.

> dpkg is open source software released under the GPL license. Apple just
> chose not to, because they would have had to open source all their code that
> linked to dpkg libraries.

> That is the price they would have to pay for piggy-backing on the efforts of
> many volunteers and gain immediate access to a state of the art packaging
> system.

Neither dpkg nor apt-get _have_ any libraries to link against, so that really
wasn't the issue.

> But of course Apple being Apple has a lot more money to spend on PR and
> along with the help of their fan boys, the story turned into "Debian
> developers are mean, capitalism-hating hippies". I am not really surprised.*

This isn't an Apple PR story. This is something I just told you, recollected
from nearly a decade ago when the mere _possibility_ of using dpkg was on the
table.

... Although, I have to say, your modern response really rather lends some
credence to my ancient recollection.

~~~
rdtsc
> Apple chose not to given the apparent community stance.

Apple still could have used it. It is open source, that is the point of open
source. Redhat might not like that CentOS is recompiling their source and
release their distribution. But there is nothing they can do.

> Neither dpkg nor apt-get have any libraries to link against, so that really
> wasn't the issue.

Not true. There is libapt, synaptic depends on it, for example. Unless they
intended their users to open terminals (oh the horror), they would have had to
link against libapt to create a responsive installer GUI. Otherwise they would
have had to parse stdout of external processes.

> This isn't an Apple PR story. This is something I just told you, recollected
> from nearly a decade ago when the mere possibility of using dpkg was on the
> table.

I understand it is not an Apple PR story in this case. It just seemed that the
story wasn't true and it seems to me often enough the untrue stories always
favor those who have most fanboys or largest PR pockets.

~~~
rbanffy
> Unless they intended their users to open terminals

They could run it on a separate process and deal with stdin/stdout within a
GUI program. No problem that way either.

~~~
rdtsc
Even better they could have assigned some devs to create dpkg and apt options
to output stdout data in a structured format (xml for ex) to facilitate this
kind of interaction. Bazaar has that for example.

The downside is that that could significantly slow down the application,
depending on the types of queries and commands that are performed.

------
tomjen3
Did they remove the global interpreter lock?

And if not, how can the language be used for high concurrency (ala Facebooks
tornado).

~~~
troutwine
In short: epoll. Network IO bound servers need only deal with sockets that
have some event ready. Unless I'm mistaken, Tornado isn't written to be highly
concurrent, it is, rather, quite asynchronous: they make it very simple to
deal with IO only when there is data to process. You _can_ block the whole
process with a long lived handler.

~~~
rbanffy
> You _can_ block the whole process with a long lived handler.

Or you could handle the event out-of-process.

~~~
troutwine
Quite so.I made my statement more to dissuade the notion that Tornado was in
any way a magic concurrency machine, that, ultimately, careful programming is
still required.

~~~
rbanffy
+1.

Out-of-process handling is no silver bullet either. Careful programming is,
but it's a skillfully handcrafted bullet, made from the most exotic materials
in addition to its silvery base and that kills only the specific problem it
was designed to kill.

Getting rid of the GIL would be like having a machine gun for mass-produced
silver bullets.

