bart4...@gmail.com writes: > On Wednesday, 12 April 2017 16:50:01 UTC+1, Jussi Piitulainen wrote: >> bart4...@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. -- https://mail.python.org/mailman/listinfo/python-list
