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/
