On Jul 30, 1:56 pm, koblas <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
