On Thu, Nov 05, 2020 at 09:41:45PM +0300, Paul Sokolovsky wrote: > Hello, > > On Thu, 5 Nov 2020 18:46:53 +0100 > Hans Ginzel <h...@matfyz.cz> wrote: > > > Is there a reason, why not to make python useful for practical one > > liners to replace perl and awk? > > There is page Powerful Python One-Liners, > > https://wiki.python.org/moin/Powerful%20Python%20One-Liners. > > But almost none of them handles files, behaves like unix filter > > or is ugly – must import modules, etc. > > > > It seems that the command line options like -a, -n, -p, -F are still > > free. :-) https://docs.python.org/3/using/cmdline.html
I wish I had a dollar for every time I called `python -c ...` from the command line and forgot to explicitly call print. The interactive interpreter's automatic printing of expressions is extremely user-friendly, in comparison `python -c` much less so. Likewise, the need to handle imports, explicit loops with newlines and indents etc makes Python much harder to use from the command line, and so much less useful. Many a time I've tried to run some quick command, couldn't get it to work. > Thankfully, command-line option "-m" is there for ages. And you're > looking for > > python3 -m <my_favorite_DSL> <any_arguments> I don't think that is what Hans is asking for. I'm pretty sure Hans is not looking for a pre-existing script to provide arguments to. He is looking to write: python <some invocation> <python code> So more like `python -c ...` than `python -m ...`, only with some boilerplate needed for file handling performed automatically. Hans even explicitly refers to `-c` in his post. Perhaps that invocation will involve `-m`, like pydoc. But I think that there is a good case for mapping such a command line helper to a single option letter, even if that ultimately ends up being managed by a script rather than built into the interpreter. > Where <my_favorite_DSL> was put on https://pypi.org/ by you or > similarly-minded people, Do you have an *actual* "my_favorite_DSL" in mind? If you don't have a well-known package in mind, how do you expect Python users in general to know which "my_favorite_DSL" will solve this problem? It might turn out that the right solution here will involve calling a script, like we call `-m unittest` or `-m doctest` etc. Maybe the best place for that is PyPI, but we shouldn't just dismiss Hans' suggestion with "just get it from PyPI". > and installed with: > > pip3 install --user <my_favorite_DSL> > > before running the previous command (needs to be done only once). Needs to be done *once per user*, *per computer*. And in many environments, that would have to be followed up by applying for unemployment benefits, assuming that you are still eligible for benefits after being fired with cause. "Just use pip" is a truly privileged position to take, one which assumes that you have the ability and legal right to install third party software on the machine you are using, with unfettered access to PyPI. In the FOSS community, it is easy to forget that this is not the norm for many people. They use school laptops or corporate machines with restrictive policies and permissions, or they have regulatory laws that require long complex audits of any software before it can be installed. Or they are sys admins who are working on production servers and they trust their own command line skills over unknown third party libraries they download off the internet. I would be very interested in exploring what it takes to make it easier to use Python from the command line. Maybe Python's enforced indentation will make this a losing proposition, but I don't think we should be so dismissive of improving the command line functionality. -- Steve _______________________________________________ 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/I46UNFPXPR2UHSEUW6VUW3M3T4HIA3TI/ Code of Conduct: http://python.org/psf/codeofconduct/