>> There is, of course, a definite downside to Inline. Your code will
>> get harder to read and maintain because you and whoever else has to
>> maintain your code has to be familiar with all the languages you are
>> inlining.
Thomas> This is more an argument against mixed language programming
Thomas> than against Inline.
Certainly. Today, you have to keep the various bits of code written in
different languages separate. Inline certainly lowers that barrier and
makes it feasible to do some spot optimizations quickly. For example,
several years ago I needed to be able to compute the distance between two
lat/longs. I wrote:
def distance(ll1, ll2):
dlat = ll1[0] - ll2[0]
longdist = (ll1[1] - ll2[1]) * math.fabs(math.cos(DEGTORAD*dlat))
return math.sqrt(MILESPERDEGLAT**2 * (dlat*dlat+longdist*longdist))
This turned out to be too slow and I wound up writing a C extension that
exposed just that one function. An Inline module would have been the
perfect solution to this problem (assuming it could figure out the shared
library needed to be linked with -lm).
Thomas> Inline makes it easier (a no-brainer) to locate the code which
Thomas> has to be changed, to determine what has to be recompiled, where
Thomas> (and how) it has to be installed, and so on.
Yes, but my original assertion still stands. With C and Python in separate
modules, I can tell people "pay no attention to the man behind the curtain"
(that being the C code). With the C code right there in the midst of your
Python code it's pretty hard to ignore the fact that the man is not behind
the curtain and he's flashing you. ;-)
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4