Python and the need for speed

Jussi Piitulainen jussi.piitulainen at helsinki.fi
Thu Apr 13 01:19:53 EDT 2017


bart4858 at gmail.com writes:

> On Wednesday, 12 April 2017 16:50:01 UTC+1, Jussi Piitulainen  wrote:
>> bart4858 at gmail.com writes:
>> 
>> > On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen  wrote:
>> >> bartc writes:
>> >> 
>> >
>> >> > These are straightforward language enhancements.
>> >> 
>> >> FYI, the question is not how to optimize the code but how to prevent
>> >> the programmer from writing stupid code in the first place. Someone
>> >> suggested that a language should do that.
>> >
>> > The 'stupid code' thing is a red herring. I assume the code people
>> > write is there for a reason.
>> 
>> So you walked in to a conversation about something that does not
>> interest you and simply started talking about your own thing.
>> 
>> Because of course you did.
>> 
>> I get confused when you do that.
>
> Huh? The subject is making Python faster. It's generally agreed that
> being very dynamic makes that harder, everything else being equal.

Amazingly, the references in this part of the thread work all the way
back to the point were you joined in. Let me quote extensively from the
message to which you originally followed up. I lay it out so that I can
add some commentary where I point out that the topic of the discussion
at that point is whether a programming language should prevent people
from writing bad code.

[Rick Johnson, quoted by Steven D'Aprano]
|     high level languages like Python should make it difficult, if not
|     impossible, to write sub-optimal code (at least in the blatantly
|     obvious cases).

That's the topic of the discussion at that point: whether it should be
difficult to *write* bad code in the language. I don't know what else
Rick may have said in his message, but Steven chose that topic for that
message.

Not whether a language should be such that the compiler could produce
efficient code, or whether the compiler should be such that it could
produce efficient code even if the language makes it a challenge, but
whether it should be difficult to write blatantly sub-optimal code.

[Steven D'Aprano, in response]
|     You mean that Python should make it impossible to write:
|
|        near_limit = []
|        near_limit.append(1)
|        near_limit = len(near_limit)
|
|     instead of:
|
|        near_limit = 1
|
|     ? I look forward to seeing your version of RickPython that can
|     enforce that rule.

You snipped that. Steven asks whether Rick really thinks that Python
should prevent that code from being written. Steven also pointed out
that this example came from some actual code :) [*I* snipped that.]

It's not a question how to produce efficient code for that, or how
Python prevents the compiler from producing optimal code. It's a
question of the compiler rejecting the code.

Traceback (most recent call last):
  File "/dev/fd/63", line 37, in <module>
SanityClauseException: code is blatantly sub-optimal

As far as I know, no language does that. Because reasons?

[Steven D'Aprano, in response]
|     Here's another example:
|
|        answer = 0
|        for i in range(10):
|           answer += 1
|
|     instead of 
|
|        answer = 10
|
|     So... how exactly does the compiler prohibit stupid code?

That was Steven's second example, which Steven again used to ask Rick
whether or how he really thinks the compiler should prohibit such code.
(I have no idea whether that discussion has continued in other branches
of the thread, or whether Rick really thinks that, but he seemed to be
saying something like that.)

You chose to comment on that example, but I think you chose to ignore
the question of prohibition altogether, even though that was the
question in this particular exchange between Rick and Steven. You went
on to address the actual compilation challenges instead.

It's a valid topic but it's a different topic. It fits under the subject
line, but not in response to that particular message. Those example
snippets were intended as a *different kind of challenge*.

That's why your original response had me confused, briefly, and then
irritated, slightly. That's all.


More information about the Python-list mailing list