Mac vs. Linux for Python Development

[twiz]

Hello,

I'm sure this is a common question but I can't seem to find a previous thread that addresses it. If one one exists, please point me to it.

I've been developing with python recreationally for a while on Ubuntu but will soon be transitioning to full-time python development. I have the option of using a Mac or Ubuntu environment and I'd like to hear any thoughts on the pros and cons of each. Specifically, how's the support for numpy and scipy? How are the IDEs?

Since I generally like working with a Mac, I'd like to hear if there are any significant downsides to python dev on OsX.

Thanks

 

[Andriy Kornatskyy]

I used to do core python development using debian linux (gnome). All way long work just fine. However recently I have had a chance to try MacOS X 10.8 and later 10.9. I used macports.org to setup everything I found “missing”.

Vim works fine regardless the platform… quite happy.

Thanks.

Andriy Kornatskyy

 

[twiz]

Hi Chris, thanks for the reply.

Yes, I agree. The main consideration is always the development experience. However, I do know that python has had some problems with other OSs (notoriously windows) and I want to avoid unnecessary compatibility issues.

Can you elaborate on some of the problems running python on OSX (or point me to a relavant link)?

Thanks

Tommer

 

[Chris Angelico]

Can you elaborate on some of the problems running python on OSX (or point me to a relavant link)?

You could poke around on the archives of this list and python-dev, but
the best link I have handy is this, which has only a brief note:

http://www.python.org/download/releases/3.3.4/

ChrisA

 

[Günther Dietrich]

I've been developing with python recreationally for a while on Ubuntu but will
soon be transitioning to full-time python development. I have the option of
using a Mac or Ubuntu environment and I'd like to hear any thoughts on the
pros and cons of each.

I've been working with Windows, Unix/Linux (X) and Max OS since 1989. In
my experience the GUI of Mac OS is the most user friendly of the the
three.

Specifically, how's the support for numpy and scipy?
How are the IDEs?

Since I generally like working with a Mac, I'd like to hear if there are any
significant downsides to python dev on OsX.

Eclipse and the PyDev and MercurialEclipse plug-ins are available for
Windows, Linux and Mac OS.
So, if I had the choice, I would go with the Mac.



Best regards,

Günther

 

[Dave Cook]

I've been developing with python recreationally for a while on
Ubuntu but will soon be transitioning to full-time python development.
I have the option of using a Mac or Ubuntu environment and I'd like to
hear any thoughts on the pros and cons of each. Specifically, how's
the support for numpy and scipy?

I had problems trying to build my own scipy stack on Maverick, but
installing Anaconda's Python distribution solved that.

Overall, Python works very well on OS X, but feels better integrated
to me under Linux.

I'll note that Macs are very popular among the members of pythonsd. I
think this is particularly true of the Django developers.

Dave Cook

 

[Michael Torrie]

I've been developing with python recreationally for a while on Ubuntu
but will soon be transitioning to full-time python development. I
have the option of using a Mac or Ubuntu environment and I'd like to
hear any thoughts on the pros and cons of each. Specifically, how's
the support for numpy and scipy? How are the IDEs?

I know a lot of Mac developers that love the Sublime text editor. And
if you combine it with https://github.com/lunixbochs/actualvim, it's
even better.

Personally OS X's focus policy drives me absolutely bonkers as a
developer. And I can't function without alt-middle clicking to size
windows and alt-click to move windows.

Since I generally like working with a Mac, I'd like to hear if there
are any significant downsides to python dev on OsX.

You can always run a virtual machine on OS X and have the best of both
worlds.

 

[Michael Torrie]

I know a lot of Mac developers that love the Sublime text editor. And
if you combine it with https://github.com/lunixbochs/actualvim, it's
even better.

Sublime is actually on all platforms, and lots of people like it.

http://www.sublimetext.com/

Personally I just use vim on any platform.

 

[Chris Angelico]

If you go for Linux, know that ubuntu would not be the first choice, ubuntu prefers user experience over stability. Debian for instance is a distribution largely used in the industry.

What you'll generally find, actually, is that there's very little
effective difference between one distro and another - there's a lot of
usability difference between, say, Xfce and GNOME3 and Mate and Unity
and so on, but you can get each of those on any Linux that supports
them (personally, I like Xfce, which I use with Debian; you can get
Xubuntu which comes with it). There's also a huge difference between
Python 2.4 and Python 2.7, but beyond the fact that Red Hat 5 happens
to ship with 2.4 and Debian Wheezy happens to ship with 2.7, there's
no connection between that and your distro. Especially among the
families of related distros (Debian and Red Hat being the patriarchs
of huge family trees, and Ubuntu being head of a major sub-tree under
Debian), you'll usually find there's not a huge amount of fundamental
difference.

So pick any distro that strikes your fancy! Try it out! If it doesn't
work out, pick a different one. Start with one that your friends use
(if you have any), that way you can get immediate help.

ChrisA

 

[Mark H. Harris]

I'm sure this is a common question but I can't seem to find a previous thread that addresses it. If one one exists, please point me to it.

My personal preference for writing and testing python code is Gnu/Linux as a platform (free libre open easier to build from C sources etc). As an editor, VI of course. Although, I can honestly say I've been using the latest GNU Emacs lately. It has a very nice python mode. I also use TextWrangler from time to time (can be extended with scripts and it has the same 'feel' as the IDLE editor (kind-of).

The main problem you will see with OSX (if you're not careful) is that IDLEwill be unstable. To be fair about it, its not IDLE's problem, per se. Its about tcl/tk tkinter. DO NOT use the built-in tcl that comes from Apple, nor the one that comes through the Apple store! Actually go to the Active TCL site and download the version related to your system (yes there is a different one depending on 10.5 10.6 etc).

Py3.3.4 and the latest Active TCL are stable on OSX 10.6 or higher. I have been very pleased with IDLE on both Gnu/Linux and OSX ( I refuse to use Windows ever again, ever) and my latest experience has been fabulous, really. My hat is off to the folks that have made IDLE the simple stable and powerful IDE that it is. I am being genuine about this.

Another reason for using Gnu/Linux (and/or OSX) is that generally they are faster. Faster loading, and faster running. Serious. I have been hearingof (4) second import times for decimal, for instance. Its almost instantaneous on Gnu/Linux, or OSX. Also, run times are considerably faster. That has less to do with the Windows version of python, and more to do with the Windows version. YMMV

If you want to extend your python code with C (as many of us do) well OSX and/or Gnu/Linux are your best bets there too, and frankly Gnu/Linux is the better of the two (from personal experience). OSX 10.6 uses the GNU gcc compiler by default, but the Apple idiosyncratic approach to builds can be annoying. Although, its minimal really (hardly worth mentioning). If you want to build python from sources (as many of us do) my personal opinion is alsothat Gnu/Linux is the way to go there too.

I agree with most of the rest of the posts here that personal preference isat play primarily. Your editor run environment is going to be more important to you than your platform. There is one main difference to that, and it has to do with what you're used to. In IDLE on Gnu/Linux the menu options are on the top of the IDE. In OSX they are on the OSX tool bar at top left(where they are for every other OSX app). OSX guys don't mind this, but Gnu/Linux guys hate it (sometimes). Also, the menu items on Gnu/Linux can be'torn' off (its a tcl/tk tkinter thing) and on OSX that does not work. Also the 'Options' menu item on OSX has nothing in it. The Options menu is in Preferences in the IDLE drop down on the OSX tool bar. Other than those things, I have spent many cheerful hours in the OSX IDLE editor and have beenhappy as a clam. Same goes for the Gnu/Linux IDLE editor.

If you want to use terminals on OSX you'll want to install Quartz and runthe terminal on the emulated X environment. It works better for python IMHO. The built-in terminal for OSX need serious configuring (which is possible) because its color is bad, and its tiny by default, with a crummy font.All of that can be changed, but it just works better to use XQuartz.

Enjoy

Cheers

 

[Chris Angelico]

Py3.3.4 and the latest Active TCL are stable on OSX 10.6 or higher. I have been very pleased with IDLE on both Gnu/Linux and OSX ( I refuse to use Windows ever again, ever) and my latest experience has been fabulous, really.. My hat is off to the folks that have made IDLE the simple stable and powerful IDE that it is. I am being genuine about this.

Another reason for using Gnu/Linux (and/or OSX) is that generally they are faster. Faster loading, and faster running. Serious. I have been hearing of (4) second import times for decimal, for instance. Its almost instantaneous on Gnu/Linux, or OSX. Also, run times are considerably faster. That has less to do with the Windows version of python, and more to do with the Windows version. YMMV

The point of this thread isn't really about Windows, so I'll try to
keep it brief, but there are a couple of things I should clarify. The
first one is about the 4+ second import time for decimal. I cited
that, recently, and comparing that with "almost instantaneous" on
Debian (which is what I experience) isn't entirely fair, because it's
more about cold cache versus warm cache. (When I shut down IDLE and
fire it up again, I get sub-second import time. Not as fast as the "so
quick as to be immeasurable" that my Debian box gave, but still
quicker than the 4ish second cold cache.)

Actually, I do find that my Linux boxes manage their disk caches far
better than my Windows boxes do. Not sure if that's Linux versus
Windows, or the ext3/4 versus NTFS file system drivers, or something
else, but a warm cache on any of my Linux boxes gives a *huge*
advantage, and my Windows boxes still show it a bit slower.

ChrisA

 

[Ned Deily]

[...]
The main problem you will see with OSX (if you're not careful) is that IDLE
will be unstable. To be fair about it, its not IDLE's problem, per se. Its
about tcl/tk tkinter. DO NOT use the built-in tcl that comes from Apple, nor
the one that comes through the Apple store! Actually go to the Active TCL
site and download the version related to your system (yes there is a
different one depending on 10.5 10.6 etc).

The gory details are here:
http://www.python.org/download/mac/tcltk/

TL;DR You'll need to install newer versions of Python (like those
download from python.org) that link with third-party builds of Tcl/Tk
rather than use the Pythons and Tcl/Tk that Apple ships with OS X 10.6+.

[...]
If you want to use terminals on OSX you'll want to install Quartz and run
the terminal on the emulated X environment. It works better for python IMHO.
The built-in terminal for OSX need serious configuring (which is possible)
because its color is bad, and its tiny by default, with a crummy font. All of
that can be changed, but it just works better to use XQuartz.

That certainly is a matter of preference. There are plenty of drawbacks
to using X11-based apps on OS X. I wouldn't advise new users to OS X to
go that route unless they were really set on using X11 entirely and, in
that case, why use OS X at all? If you don't like Apple's built-in
Terminal.app, another option is to use iTerm 2, an open source native
alternative that has many more features.

http://www.iterm2.com/

It's also available through MacPorts.

 

[Frank Millman]

The point of this thread isn't really about Windows, so I'll try to
keep it brief, but there are a couple of things I should clarify. The
first one is about the 4+ second import time for decimal. I cited
that, recently, and comparing that with "almost instantaneous" on
Debian (which is what I experience) isn't entirely fair, because it's
more about cold cache versus warm cache. (When I shut down IDLE and
fire it up again, I get sub-second import time. Not as fast as the "so
quick as to be immeasurable" that my Debian box gave, but still
quicker than the 4ish second cold cache.)

Which version are you talking about?

I have an old, slow box running Windows Server 2003 and python 3.3.2.

I have just booted it up now, called up a command prompt, typed 'python' to
start the interpreter, and typed 'import decimal'. The interpreter prompt
re-appeared in the blink of an eye.

Are you talking about something else?

Frank Millman

 

[Chris Angelico]

Which version are you talking about?

I have an old, slow box running Windows Server 2003 and python 3.3.2.

I have just booted it up now, called up a command prompt, typed 'python' to
start the interpreter, and typed 'import decimal'. The interpreter prompt
re-appeared in the blink of an eye.

Are you talking about something else?

I did it in IDLE, which might have added a bit, but not hugely. It was
3.4.0, so the module in both cases is the C-accelerated version. My
suspicion is that you've used the decimal module already on that
system, so you had a warm cache. When I repeat the exercise, I get
sub-second load times (usually of the order of 100-200ms); the
difference between that and your "blink of an eye" would be to do with
exactness of measurement, CPU/HDD performance, etc, etc, etc.

ChrisA

 

[Frank Millman]

I did it in IDLE, which might have added a bit, but not hugely. It was
3.4.0, so the module in both cases is the C-accelerated version. My
suspicion is that you've used the decimal module already on that
system, so you had a warm cache. When I repeat the exercise, I get
sub-second load times (usually of the order of 100-200ms); the
difference between that and your "blink of an eye" would be to do with
exactness of measurement, CPU/HDD performance, etc, etc, etc.

I assume by 'warm cache' you mean that I had used the decimal module before
and not switched the machine off before trying the above exercise.

In my case, the machine was switched off before I started. I switched it on
and executed the above steps.

To be slightly more precise, instead of 'the blink of an eye', I estimate it
was between 250-500 ms. If I close the interpreter and start it up again, it
takes maybe 100-200ms.

Just to be sure, I switched the machine off and on again, and repeated the
exercise. Starting the interpreter for the first time takes 1.5 - 2 seconds.
Importing decimal for the first time takes less than 500ms.

Frank

 

[Chris Angelico]

I assume by 'warm cache' you mean that I had used the decimal module before
and not switched the machine off before trying the above exercise.

In my case, the machine was switched off before I started. I switched it on
and executed the above steps.

That would be about it, yeah. So that would be a cold cache test.

To be slightly more precise, instead of 'the blink of an eye', I estimate it
was between 250-500 ms. If I close the interpreter and start it up again, it
takes maybe 100-200ms.

Alright, so now we're talking about some other factors on my system
that slow down the cold cache load dramatically. That I can completely
understand; when I originally posted it, I was fully aware that the
exact figures wouldn't be duplicable. 500ms is a major delay to
startup; but what's really significant is the 100-200ms warm cache,
because that one is what's going to be repeated. (Imagine a web server
that periodically restarts its subprocesses - say, every N requests.
Adding 200ms to startup time effectively adds 200/N ms to every
request.)

An awesome disk cache can improve that immensely, though. My Debian
box, warm cache, takes 0.0 seconds to import decimal. But it's a
faster computer overall, so even cold cache it only takes a hundred ms
or so.

Just to be sure, I switched the machine off and on again, and repeated the
exercise. Starting the interpreter for the first time takes 1.5 - 2 seconds.
Importing decimal for the first time takes less than 500ms.

I'm beginning to get a suspicion here that the Windows XP disk cache
actually might have a "most pessimal" state, where it's full of other
stuff. Worse than a cold cache in performance, a cache warmed by
something else. But in any case, the exact figures for cold cache are
almost immaterial compared to a noticeable warm-cache delay - if
there's enough work to be done just loading the .pyc from the disk
cache that it takes visible time, then it would be a problem to force
that to be loaded on every interpreter startup. Which was kinda the
point of my original testing - I wanted to know how much of a penalty
there'd be to moving decimal to built-in.

ChrisA