Native Code vs. Python code for modules
wuwei23 at gmail.com
Wed Jul 30 06:32:30 CEST 2008
On Jul 30, 1:56 pm, koblas <kob... at gmail.com> wrote:
> Ruby has been getting pummeled for the last year or more on the
> performance subject. They've been working hard at improving it. From
> my arm chair perspective Python is sitting on it's laurels and not
> taking this as seriously as it probably should.
Well, the snarky response is most Python developers are too busy
working on actual real world projects :)
A more measured response would be that it's so easy to integrate
Python with C that most developers would prefer to profile their own
code and implement bottleneck code in C where appropriate.
> In general it's
> possible to make many comments that swirl around religion and
> approach, one of the things that I've noticed is that wile Python has
> a much more disciplined developer community they're not using this for
> the greater good.
I guess it all depends on what you define by "greater good". If you
mean "faster performance", then maybe not, although it definitely
seems to be -one- aspect being addressed by the PyPy project, at
least. For me, "greater good" == "makes my life as a developer
easier", and from that definition I've nothing but admiration for the
community as a whole.
> This got me to think, why does python have "pickle" and "cPickle"?
Because sometimes you want something to be fast, but other times you
want a pure Python version that's easy to extend.
> To that end why would somebody write big try catch blocks to see if
> modules exist and if they exist alias their names.
Because it's the established approach, they're run through once during
importing, and it doesn't require modifying the language to achieve
> Wouldn't it be
> better if there was a way that if I have an "interface compatible"
> native (aka C) module that has better performance that there could be
> a way that python would give it preference.
Shouldn't that -always- be decided by the developer? I don't want to
rely on magic behaviour based on what is installed in the runtime
environment by an end user...
> import random(version=1.2, lang=c)
> import random(version=1.2, lang=py)
I don't see the gain over sticking with an established convention,
like pickle and cPickle.
> import random # use the latest version in the "fastest" code (C
> given preference)
I personally have a preference for predictable behaviour over
All of this, of course, is personal preference; please don't take me
for a jihadi :)
More information about the Python-list