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.
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.
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?
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.
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:
I'm not sure what makes Homebrew better than MacPorts. Most of their self-declared advantages -- the largest one being that they don't replicate OS-provided software -- are going to fall over as soon as the software included with Snow Leopard starts getting a bit stale.
Case in point, Snow Leopard ships with Python 2.6, and now people are going to want 2.7.
[Edit]
I think it's also enlightening to look at this breakdown of the advertised homebrew features circa last year:
I don't think it's perfect, but I can tell you why I have come to prefer Homebrew:
1. It's far faster. Installations and all operations take less time.
2. It's far lighter. Sure disk space is cheap, but why waste if I can avoid it?
3. It's written in a language I know well enough to contribute. (Ruby as opposed to Tcl.) And Github is Homebrew's secret weapon here. There are literally hundreds of us with forks, providing constant updates. Packages are updated far faster than Fink or MacPorts. Momentum counts.
4. They maintain a branch dedicated to providing duplicates, where people really want them. I install Vim in just this way, and they in fact provide multiple versions of Python.
That said, it's not for everyone. I didn't object to MacPorts. The only option I really think is bad is overwriting the system's Python, as I said.
Replying again since you updated in response to my questions =)
1. It's far faster. Installations and all operations take less time.
That hasn't been my experience, but have you checked the latest release? It switched the local installation information to sqlite, which seems to make things mighty fast.
2. It's far lighter. Sure disk space is cheap, but why waste if I can avoid it?
Because the "we won't replicate dependencies" thing won't survive another full OS X release cycle. Snow Leopard was a rushed release cycle that brought a quick refresh to the OS-supplied components, but it was a once-off and it's not going to happen again soon, especially given the focus on iOS.
3. ... And Github is Homebrew's secret weapon here. There are literally hundreds of us with forks, providing constant updates. Packages are updated far faster than Fink or MacPorts. Momentum counts.
That doesn't seem to match reality. Take the current case; MacPorts:
* Has been tracking Python2.7 releases since its alpha release 5 months ago.
* Provides ports for python 2.4, 2.5, 2.6, 2.7 and 3.1 (all of which are not always backwards compatible)
Homebrew is tracking only Python2.6, didn't have any Python2.7 submissions until yesterday, and hasn't integrated the change into mainline.
When they -do- integrate the change into mainline, everybody is going to have to deal with the headaches that invariably occur across minor releases of Python[1], rather than tracking the multiple versions they require, because homebrew has a naively simple and ultimately flawed policy of "only one version".
Most of the complexity in MacPorts and Fink is a direct result of understanding the complexity of the problem space over a decade. Homebrew will become just as complex as time reveals the necessity of many of these compromises.
Faster in the simplest sense: sudo port install x takes longer to finish than brew install x. Lighter in just as straightforward a sense: same installations, less space used (fewer dependencies I suppose).
The "it's Ruby" argument was entirely personal. I like to hack and help, if I can. Here I can.
Rudix provides binaries, but fewer packages.
The funny thing is that not that long ago, I was as skeptical as anyone. I installed Homebrew only recently when I updated two machines to Snow Leopard - mostly to prove to myself it wasn't just inertia and stubborn keeping me with MacPorts. I stayed with it because it works so well.
I didn't update my post in reply to you. I often write a quick reply and then do a bunch of expanding edits. Bad habit- sorry. I haven't tried MacPorts in a few months. Maybe it's much faster. I got very, very tired of editing the Python portfile to remove the TK dependency that dragged in an entire xorg system. But I think that deep is now optional. Again, I don't have a religious attitude towards Homebrew. I tried it, and I'm very happy with it for now.
But you don't overwrite OSX's python, the new version is installed side-by-side. The installation also creates links to the new version into /usr/local/bin, so that it doesn't mess up the system's python. Never had any trouble with this.
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?
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.
> 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.
> 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.
> 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.
> Apple still could have used it. It is open source, that is the point of open source.
Yes, but Apple chose not to. It had nothing to do with legal reasons.
> Not true. There is libapt, synaptic depends on it, for example.
Sorry, you're correct. There was a nascent libapt, but at the time, we just wanted dpkg, and as rbanffy noted, we could always run apt as a separate binary.
It really wasn't a "fear the GPL" response.
> 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.
OK. But it's why I was told we couldn't use dpkg. I don't know if you recall what Apple and Mac OS X was like before the 10.0 release, but both were very different beasts than they are today, and Apple had some very different priorities in respect to UNIX, the existing UNIX community, et al.
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.
Short answer: it's not you; it's Apple, mostly. There is nothing for OSX as good as the APT tools. Apple provides a good selection of nix tools, but it cripples some, rarely updates them and has zero investment in a larger tool-set for dealing with them.
All the community solutions are imperfect. What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local. (That's pretty common.) Welcome to *nix package management, sadly.
> What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local.
It's actually worse than this; MacPorts maintains its own idea of what's installed, and, while you can put your files in its directories, that won't fool it into believing that ImageMagick is installed if it hasn't done it itself. (People have asked MacPorts for ways to work around this—to avoid installing all the X libraries again just to use an X application, for example—but, as near as I can tell, this is a design decision.)
Also, it's 'true enough', but not always true, that MacPorts looks in /opt/local. For example, I'm finicky about having one easily backed-up directory for everything that I install, so mine is in /Users/Shared/Applications/Utilities/MacPorts (much easier to type, no? :-) ).
> ... near as I can tell, this is a design decision.
Yes. A very long time ago, MacPorts relied on file dependencies; if a library was there, it was used.
The problem that emerged was that these dependencies often broken. Sometimes Apple shipped a broken update, sometimes users installed broken software.
This would cause MacPorts to break.
If Apple shipped a broken update (eg, openssl headers that didn't match the openssl library), MacPorts had to switch to their own openssl package in order to be able to keep building software.
If users installed broken, too-old, or otherwise non-suitable packages, the MacPorts developers had to help debug their rather random systems to figure out the problem.
When you couple this with OS-shipped dependencies that go stale, you necessarily see your dependency tree begin relying on internal dependencies for almost everything, and due to all the software deployed using those dependencies, you can't cull them from the tree.
So instead you wind up maintaining a controlled, parallel universe. It's foolish to think this won't happen with Homebrew, too.
Compiled from source and using it from a separate folder it's fine for me. Also added easy_install from source and used that to install a few libraries like boto, readline, ipython, etc. without a problem.
The next 'port sync' will override your local portfile changes. If you want to keep them, you can also copy the port somewhere else, or even set up your own local tree of port files. ('port dir python27' to get the path to the port for copying).
Also, if you fail to update the checksum, port(1) will tell you what it should be (which is how I got the line to use above).
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.
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.
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.
