Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Programming in Python.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -313,7 +313,7 @@
"metadata": {},
"source": [
"## Python is a (relatively) fast language\n",
"This one might seem a bit surprising; on its face, the claim that Python is a fast language may seem silly, because, in benchmarks comparing Python with compiled languages like C or Java, Python typically [gets smoked](https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gpp). And there's no question that, if speed is of the essence (e.g., you're writing a 3D graphics engine, or running massive fluid dynamics simulations), Python is probably not going to be your language of choice (or even the second best language, for that matter). BUT, in practice, the limiting factor in many scientists' workflow is not execution time but development time. A computationally inefficient script that takes an hour to write but only five minutes to write is often preferable to one that takes five seconds to run, but a week to write and debug. Moreover, as we'll see below, even in cases where all of our code is written in Python, a little bit of optimization can often make it run almost as fast as a native C solution. In practice, for most scientists, there are not very many situations where a Python-based solution is not fast enough to work--and the number of such cases is decreasing rapidly as the tooling improves.\n",
"This one might seem a bit surprising; on its face, the claim that Python is a fast language may seem silly, because, in benchmarks comparing Python with compiled languages like C or Java, Python typically [gets smoked](https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gpp). And there's no question that, if speed is of the essence (e.g., you're writing a 3D graphics engine, or running massive fluid dynamics simulations), Python is probably not going to be your language of choice (or even the second best language, for that matter). BUT, in practice, the limiting factor in many scientists' workflow is not execution time but development time. A computationally inefficient script that takes an hour to run but only five minutes to write is often preferable to one that takes five seconds to run, but a week to write and debug. Moreover, as we'll see below, even in cases where all of our code is written in Python, a little bit of optimization can often make it run almost as fast as a native C solution. In practice, for most scientists, there are not very many situations where a Python-based solution is not fast enough to work--and the number of such cases is decreasing rapidly as the tooling improves.\n",
"\n",
"### Don't reinvent the wheel\n",
"A general principle in software development is that reinventing the wheel should be avoided when possible. Of course, sometimes it *isn't* possible, and there are many cases where it makes sense to write your own solution to a problem, or create an entirely new tool. But as a general rule of thumb, the less Python code you write yourself, the better your performance will be. There are several reasons for this:\n",
Expand Down