Native Code vs. Python code for modules

[alex23]

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
it.

> 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)
> or
>   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
idealised optimisation.

All of this, of course, is personal preference; please don't take me
for a jihadi :)

- alex23