On Sunday, February 25, 2018 at 8:45:56 PM UTC-6, Chris Angelico wrote:
> On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson
[...]
> > but i do wish we pythonistas had a method to turn off this
> > (and other) cycle burning "features" -- you know -- in the
> > 99.99999 percent of time that we don't need them.
>
> Definitely. We should also provide a way for people to
> manually allocate memory, for the times when that would be
> more efficient. And to switch out the syntax to include
> braces.
Now you're throwing the baby out with the bath water.
We needn't re-implement the C language simply to achieve
reasonable and practical code-execution efficiency. Python
was never intended to be the fastest language. Heck! Python
was never intented to be the fastest _scripting_ language!
So of course, speed is not and should not be the primary
concern, but to say that execution speed is of _no_ concern
is quite absurd indeed.
As Steven mentioned, few people, even of they _could_ afford
the absurd price, will ever purchase that high-end sports
car. However, by using this example Steve is committing the
argumentation sin of comparing apples to oranges because
transportation is more a matter of practicality. Sure, you
may arrive at your destination more quickly in the high-end
sports car, however, the trade-off will be that you could be
thrown in jail for speeding or be injured or killed in an
accident.
But such existential risks are not the case for software...
Code that execute more quickly simply (wait for it...) yes,
executes more quickly! And I can assure you: no one will die,
be injured, or even become "Bubba's" cell mate should their
code commit the unforgivable "sin" of executing more
quickly[1].
--
[1] Quick! Someone please call a priest! We need to confess!!!
--
https://mail.python.org/mailman/listinfo/python-list
