Everything good about Python except GUI IDE?

[Chris Angelico]

On Wed, Mar 2, 2016 at 12:51 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Wed, 2 Mar 2016 05:06 am, Marko Rauhamaa wrote:
>
>> Steven D'Aprano <steve at pearwood.info>:
>>
>>> On Sun, 28 Feb 2016 11:38 pm, BartC wrote:
>>>> It's the GUI users who are the Neanderthals, having to effectively
>>>> point at things with sticks. Or have to physically move that rock
>>>> themselves (ie. drag a file to a wastebasket).
>>>
>>> I haven't physically moved an icon to the wastebasket for years. I
>>> point at the icon, right-click, and tell it "move yourself to the
>>> trash".
>>
>> Do you find that interface convenient? Do you often find yourself
>> clickety-clicking around to perform bulk file operations?
>
> Sometimes. Especially with media files which display a thumbnail, it is far
> more convenient to be able to look at the icon and recognise the file than
> to try to guess from the filename "x73nfh.jpg". And having recognised the
> file visually, its often easier to drag it into the folder of your choice
> than to type "mv x7<tab> dir<tab>" in a separate window.
>
> But not always. It's much easier to do "mv foo* dir<tab>". Horses for
> courses.

Absolutely. Tab completion *ROCKS* when you know the file name -
point-and-click is *SUPERB* when you want to identify things by some
form of metadata that the GUI can pull out and display (image/video
file thumbnails being one example; executable files can include their
own icons, esp on Windows; etcetera). The downside of the GUI, here,
is that it sometimes is quite costly to generate those thumbnails; tab
completion is done by reading the directory, but thumbnailing a bunch
of JPGs requires reading the file contents (even if you were actually
planning on clicking on one of the text files in the same directory).
Like you say, horses for courses; but in many cases, I'd recommend
starting with the cheap option - the command line - and moving to the
costlier one only in the situations where you know it's of value.

>> What I'm thinking is, could Python turn into a serious competitor to
>> bash? The standard shell suffers greatly from sloppy quoting, and many
>> of the age-old list-processing idioms are more awkward than cute.
>
> No. Python's syntax is too wordy to make a good shell. You need brackets and
> quote marks for everything:
>
> # bash
> ls foo/bar
>
> # Python
> ls("foo/bar")
>
> iPython is usable, by adding non-standard syntax to its REPL. I don't think
> it's a serious contender as replacement for bash, but you could give it a
> try. But the standard Python REPL? No.

>> A python shell would need a well-thought-out default import plus a way
>> to string together external commands. Maybe JSON or similar could be the
>> standard I/O framing format (instead of SPC-separated fields and
>> LF-separated records).

I think the non-standard syntax plan is the way to do it. But the
thing is, you either have a code-like structure where you delimit
everything, or you have the messy rules involving quoting and
interpolation. The well-established basic shell syntax of
space-delimited parameters with optional quoting is a great balance
between verbosity and complexity.

Not sure what "LF-separated records" has to do with "SPC-separated
fields", though. The latter is all about how you type a command, and
the former is all about the way different commands interact via stdin
and stdout.

> You really want to be typing JSON by hand instead of space-separated
> fields/arguments?
>
> # Python using JSON
> ls('["-l", "foo/bar", "spam/ham"]')
>
> # bash
> ls -l foo/bar spam/ham
>
> Bugger that for a game of soldiers.

No kidding, but at least it's consistent. Maybe there's a
middle-ground, where it's still perfectly consistent, while not being
quite as verbose?

ChrisA