On 2020-11-20 20:53, Chris Angelico wrote:
So let me ask this: In what circumstances do you think producing native executables IS a bad thing, and in what circumstances do you think it ISN'T a bad thing, and why do you think including such functionality in the stdlib would encourage the former more than the latter?
It's a bad thing any time it isn't actually necessary, and it's a good
On Sat, Nov 21, 2020 at 3:35 PM Brendan Barnwell<brenbarn@brenbarn.net> wrote: thing only when it is actually necessary. It's not my place to argue other people's use cases in specifics, but I'm just saying that the default should be to NOT bundle the interpreter, and you only reach for a native executable if that doesn't work.
Okay, but that doesn't answer the second part of my question. You were saying earlier that you wanted people to read your posts and not claim that you're saying native executables shouldn't exist. So I'm trying to bring the discussion back to the original more narrow topic, which is the pros and cons of including native executable creation in the stdlib. Just saying "it's bad if it's not necessary" is a cop-out in this context. The question is why do you think that including such functionality in the stdlib is bad. Your response here is saying it's up to other people to decide whether to use it or not, but that doesn't explain why you think it shouldn't be in the stdlib. Everything in the stdlib can be used if people think it's necessary and not used if they don't.
Under what circumstances should you use subprocesses and pipes in a Python program, and under what circumstances should you just keep everything inside a single process? Should you just always use boilerplate that runs everything in multiple processes in case you need to run it across multiple CPU cores? No. Does this mean I'm arguing against ever using multiple processes? No.
This example seems to quite contradict the view that executable bundling shouldn't be in the stdlib. You're saying "don't create a native executable unless necessary" and "don't use multiple processes unless necessary". But we do have multiprocessing in the stdlib. Why is including a native executable creator in the stdlib any more insidious than including multiprocessing? If people aren't throwing multiprocessing boilerplate in where they don't need it, why should we assume they'll throw in native-executable boilerplate where they don't need it? -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown