On Jul 30, 1:56 pm, koblas <kob...@gmail.c omwrote:
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.
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.
Because sometimes you want something to be fast, but other times you
want a pure Python version that's easy to extend.
Because it's the established approach, they're run through once during
importing, and it doesn't require modifying the language to achieve
it.
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...
I don't see the gain over sticking with an established convention,
like pickle and cPickle.
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
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.
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.
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.
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.
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"?
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.
modules exist and if they exist alias their names.
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.
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.
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)
or
import random(version= 1.2, lang=py)
like pickle and cPickle.
import random # use the latest version in the "fastest" code (C
given preference)
given preference)
idealised optimisation.
All of this, of course, is personal preference; please don't take me
for a jihadi :)
- alex23
Comment