On 2020-11-20 20:53, Chris Angelico wrote:
On Sat, Nov 21, 2020 at 3:35 PM Brendan Barnwell<brenb...@brenbarn.net> 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
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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZEYETMUZPTJISPWYKV6HZRFYBLS3CITA/
Code of Conduct: http://python.org/psf/codeofconduct/
