You started the whole “reductio ad absurdum” when you ended your argument with:
which is why I then responded with reductio ad absurdum.
If I have to type or copy-and-paste all that recipe code to setup the server in a certain way I would’ve configured a full-fledged HTTP server already.
I know people often say “please go back and read my post” in a disingenuous, nasty way. But please reread where I said “Finding common ground” and tell me if it was not unclear and did not match my intent. My goal there was to state something which I think we both can agree upon.
Even if we agree on the facts we can draw different conclusions.
It sounds to me like you want Python to provide for your CLI needs? If you want a simple local webserver with CORS built in, getting it added to Python is not the only way (of course).
Can you maybe explain to me why it is better to add this to Python than to
put it in an example
release a small PyPI package which implements that example
and pipx install that tool
If my poor phrasing made you feel attacked, I am genuinely sorry about that. I am emphatically not sorry about calling you out for being hostile in return.
Of course there are tens of other ways to get a CORS-enabled HTTP server running.
I like the http.server module because it allows me to jump into a directory on any host and start serving files for a draft of a web app right away with 0 setup, but sometimes the lack of support for CORS gets in the way and I do have to fall back to actually configuring a conventional HTTP server, which is by no means a hard thing to do but still slows things down a bit.
I just feel that the proposed --cors option is a good bang for the buck as it offers meaningful convenience for the primary use of this existing module with minimal effort required, in terms of both code and maintenance.
Currently we have the port as positional so we’d need to look for the colon to handle these differently. On the other hand, a separate --header option would be easier to document and implement.