Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #48016 > unrolled thread

Re: My son wants me to teach him Python

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: My son wants me to teach him Python Joshua Landau <joshua.landau.ws@gmail.com> - 2013-06-13 21:18 +0100
    Re: My son wants me to teach him Python Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-13 20:33 -0700
      Re: My son wants me to teach him Python Chris Angelico <rosuav@gmail.com> - 2013-06-14 14:02 +1000
        Re: My son wants me to teach him Python Anssi Saari <as@sci.fi> - 2013-06-14 15:02 +0300
          Re: My son wants me to teach him Python Chris Angelico <rosuav@gmail.com> - 2013-06-15 03:12 +1000
      Re: My son wants me to teach him Python Chris Angelico <rosuav@gmail.com> - 2013-06-14 14:05 +1000
        Re: My son wants me to teach him Python Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-16 12:04 -0700
          Re: My son wants me to teach him Python Chris Angelico <rosuav@gmail.com> - 2013-06-17 07:52 +1000
            Re: My son wants me to teach him Python Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-16 15:33 -0700
              Re: My son wants me to teach him Python Alister <alister.ware@ntlworld.com> - 2013-06-17 21:11 +0000
      Re: My son wants me to teach him Python Joshua Landau <joshua.landau.ws@gmail.com> - 2013-06-14 06:11 +0100
      Re: My son wants me to teach him Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 06:13 +0000
        Re: My son wants me to teach him Python Chris Angelico <rosuav@gmail.com> - 2013-06-14 17:21 +1000
        Re: My son wants me to teach him Python Tim Chase <python.list@tim.thechases.com> - 2013-06-14 05:41 -0500
          Re: My son wants me to teach him Python Alister <alister.ware@ntlworld.com> - 2013-06-14 15:35 +0000
        Re: My son wants me to teach him Python Neil Cerutti <neilc@norwich.edu> - 2013-06-14 16:01 +0000
          Re: My son wants me to teach him Python Chris Angelico <rosuav@gmail.com> - 2013-06-15 03:14 +1000
        Re: My son wants me to teach him Python Jason Swails <jason.swails@gmail.com> - 2013-06-14 13:03 -0400
      Re: My son wants me to teach him Python Jason Swails <jason.swails@gmail.com> - 2013-06-14 02:28 -0400
      Re: My son wants me to teach him Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-14 20:12 -0400

#48016 — Re: My son wants me to teach him Python

On 13 June 2013 17:50, Tomasz Rola <rtomek@ceti.pl> wrote:
> Of course kids are more interesting in things painted on
> screen, especially if they are colorful, move and make
> sounds at that. The next step would be a simple,
> interactive game.
>
> Which is why I would synthesize something neat yet
> simple from http://processing.org/tutorials/
>
> Python is overkill for a kid. Ugh. Some people have just
> no common sense at all.

As someone who can only recently claim to be "not a kid", I will again
do my duty and counter this point.

GUI is boring. I don't give a damn about that. If I had it my way, I'd
never write any interfaces again (although designing them is fine).
Console interaction is faster to do and it lets me do the stuff I
*want* to do quicker.

Also - Python is pretty much the only language that *isn't* overkill;
once you take more than the first few steps a language that's
*consistent* will help more with learning, á mon avis, than these
"quicker" languages ever will. Python is consistent and simple.

Then, when you're better and you do want to do cool stuff,
Cython/occasionally PyPy/Numpy/Numba etc. let you get C-like speeds
learning no other languages at all (although you do need to get C
types down). That's the easy way out, not
Python-then-C-because-Python-is-slow or some nonsense like that.

Basically, "kid" is a *very* generic term and there are people who
like GUIs and there are people who like internals and there are
hundreds of other classifiers from all over the globe. Please don't
conflate groups if you can help it, as it's often just wrong.

[toc] | [next] | [standalone]

#48056

On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:

> [...]
> GUI is boring. I don't give a damn about that. If I had it
> my way, I'd never write any interfaces again (although
> designing them is fine). Console interaction is faster to
> do and it lets me do the stuff I *want* to do quicker.

And are you willing to provide *proof* that the console is
faster? Or is this merely just your "opinion"? I would be
ready and willing to compete in a "Pepsi challenge" to
disprove your claim if needed.  For instance, if i want to
open a text file on my machine, i merely navigate to the
file via my file browser interface, using clicks along the
way, and then the final double click will open the text file
using it's default program. Are you telling me you can type
the address faster (much less remember the full path) than i
can point and click? And if you think you're going to cheat
by creating an "environment variable", well i can still win
by doing the same thing with a "shortcut".

> Also - Python is pretty much the only language that
> *isn't* overkill; once you take more than the first few
> steps a language that's *consistent* will help more with
> learning, a mon avis, than these "quicker" languages ever
> will. Python is consistent and simple.

Your statement is an oft cited misconception of the Python
neophyte. I'm sorry to burst your bubble whilst also raining
on your parade, but Python is NOT consistent. And the more i
learn about Python the more i realize just how inconsistent
the language is. Guido has the correct "base idea", however
he allowed the evolution to become a train wreck.

> [...]
> Basically, "kid" is a *very* generic term and there are
> people who like GUIs and there are people who like
> internals

Your statement is true however it ignores the elephant in
the room. You can "prefer" console over GUI all day long but
that does not negate the fact that GUI's outperform the
console for many tasks. With the exception of text based
games, the console is as useful for game programming as a
cheese grater is for masturbation -- slightly amusing, but
mostly just painful!

[toc] | [prev] | [next] | [standalone]

#48058

On Fri, Jun 14, 2013 at 1:33 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>  For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program. Are you telling me you can type
> the address faster (much less remember the full path) than i
> can point and click?

I have tab completion. Beat that, GUI.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48121

Chris Angelico <rosuav@gmail.com> writes:

> I have tab completion. Beat that, GUI.

Decent GUIs *have* tab completion. Bad GUIs don't.

Oh wait. Is a GUI with tab completion a GUI at all or more of a weird
ass hybrid? What about a CLI that pops up a menu for completions?

[toc] | [prev] | [next] | [standalone]

#48187

On Fri, Jun 14, 2013 at 10:02 PM, Anssi Saari <as@sci.fi> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> I have tab completion. Beat that, GUI.
>
> Decent GUIs *have* tab completion. Bad GUIs don't.
>
> Oh wait. Is a GUI with tab completion a GUI at all or more of a weird
> ass hybrid? What about a CLI that pops up a menu for completions?

Hmm. Not sure what you mean there. The nearest I can think of is the
way the file dialog (under Debian Wheezy + Xfce + SciTE; no idea who's
responsible, probably Xfce) will fill in directory components as I
type. But that's functioning almost exclusively as CLI style; I type
in parts of the path and it does things. To take advantage of tab
completion, I ignore the GUI-style of "point to the thing you want and
click". There's no real way for point-and-click to work with tab
completion.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48059

On Fri, Jun 14, 2013 at 1:33 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it
>> my way, I'd never write any interfaces again (although
>> designing them is fine). Console interaction is faster to
>> do and it lets me do the stuff I *want* to do quicker.
>
> And are you willing to provide *proof* that the console is
> faster? Or is this merely just your "opinion"? I would be
> ready and willing to compete in a "Pepsi challenge" to
> disprove your claim if needed.  For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program.

Also - Show me an efficient way, with a GUI, to invoke any file with
any program with any parameters, without cheating and using something
like Alt-F2 to enter a command line. Your solution must be utterly
generic. I need to be able to tail -F and tail -f a file.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48468

On Thursday, June 13, 2013 11:05:00 PM UTC-5, Chris Angelico wrote:

Chris, a GUI interface can be created for *ANY* command line
functionality. By utilizing the GUI you can be more
productive because a "point" and a "click" are always faster
than "peck-peck-peck" * INFINITY. 

For instance, if i want to start a certain program (or func)
on the commandline, first i will need to know what commands
are available. To see these commands i must *FIRST* type a
command. On the windows box that command would be "help".
Now hopefully the command list will fit within the console's
buffer capacity, or else i need to enter a page buffer mode
(SOMEBODY KILL ME NOW!!!).

This is where the GUI shines!

When i choose to open my "system tools gui" (instead of the
antiquated text only console), a list of commands will be
displayed in a nice list box with scroll-bars that have near
unlimited capacity to scroll. All i need to do is "point"
and "click" and this "magical" piece of software runs
another GUI program for that specific task or tool.

> Also - Show me an efficient way, with a GUI, to invoke any
> file with any program with any parameters, without
> cheating and using something like Alt-F2 to enter a
> command line. Your solution must be utterly generic. I
> need to be able to tail -F and tail -f a file.

Just because you lack the graphical tools on your machine,
or the skill to create those graphical tools on your
machine, does not mean the rest of us are as incapable. 

Note: The following solution requires you to have a windows
OS, if you are using anything else, then you should be geeky
enough to roll your own solution!

## BEGIN SCRIPT ##
# Python Version < 3.0 only!
import sys, os
import Tkinter as tk
import tkSimpleDialog, tkMessageBox

msg1 = 'Greetings master, by what method shall i execute "{0}"?'
msg2 = """\
And the master sayeth:

"{0}"

So it is written, so shall it be done"""
ivalue = "some/path/to/nowhere.txt -opt1=foo -opt2=bar"

def prompt_master():
    argv = sys.argv
    path = argv[1]
    fname = os.path.basename(path)
    msg = msg1.format(fname)
    argstr = tkSimpleDialog.askstring('',
                                      msg,
                                      initialvalue=ivalue,
                                      parent=root
                                      )
    if argstr:
        tkMessageBox.showinfo('', msg2.format(argstr),parent=root)
        os.system('{0} {1}'.format(path, argstr))
    root.destroy()

if __name__ == '__main__':
    root = tk.Tk()
    root.withdraw()
    prompt_master()
    root.mainloop()
## END SCRIPT ##

Save that code in a file named "PepsiChallenge.py", then
throw that script in your "Send To" folder and it
"magically" becomes accessible from the "SendTo" command of
the windows context menu. If you don't know where to find
your windows "send to" folder then ask my good friend
Google.

To use, simply open your windows file browser, navigate to a
file icon, right click the file, and send it to the
PepsiChallenge script. 

By doing this we've harnessed the power of an existing GUI
without actually writing all the GUI code. But more
importantly we've won the challenge :-P"

*school-bell*

[toc] | [prev] | [next] | [standalone]

#48482

On Mon, Jun 17, 2013 at 5:04 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Chris, a GUI interface can be created for *ANY* command line
> functionality. By utilizing the GUI you can be more
> productive because a "point" and a "click" are always faster
> than "peck-peck-peck" * INFINITY.
>

Okay... I'm trying to get my head around what you've done here. Isn't
it simply that you've made a way to, with what looks like a
point-and-click interface, let the user type in a command line? Or
even worse, force them to edit a file to change the command used? That
already exists - as I mentioned, several desktop environments have
Alt-F2 to let you type in any program and run it. That's no more using
a GUI than bringing up a terminal is.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48485

On Sunday, June 16, 2013 4:52:16 PM UTC-5, Chris Angelico wrote:

> Okay... I'm trying to get my head around what you've done
> here. Isn't it simply that you've made a way to, with what
> looks like a point-and-click interface, let the user type
> in a command line? 
> [...] 
> That's no more using a GUI than bringing up a terminal is.

Yes, a Graphical Interface will need the occasional "peck-peck" input from the user, the only difference from a text based interface is the INFINITY multiplier. The Graphical Interface prefers the point and click, but NOT exclusively! The Graphical Interface allows you apply the most efficient method by which to solve a problem -- again, that might be "peck-peck" or "point-click", OR, a combination of both. Depends on the situation really. 

[toc] | [prev] | [next] | [standalone]

#48565

On Sun, 16 Jun 2013 15:33:29 -0700, Rick Johnson wrote:

> On Sunday, June 16, 2013 4:52:16 PM UTC-5, Chris Angelico wrote:
> 
>> Okay... I'm trying to get my head around what you've done here. Isn't
>> it simply that you've made a way to, with what looks like a
>> point-and-click interface, let the user type in a command line?
>> [...]
>> That's no more using a GUI than bringing up a terminal is.
> 
> Yes, a Graphical Interface will need the occasional "peck-peck" input
> from the user, the only difference from a text based interface is the
> INFINITY multiplier. The Graphical Interface prefers the point and
> click, but NOT exclusively! The Graphical Interface allows you apply the
> most efficient method by which to solve a problem -- again, that might
> be "peck-peck" or "point-click", OR, a combination of both. Depends on
> the situation really.

You have now completed the circle back to where everone else has always 
been " use the correct tool for the job"

I believe that most programmers would probably follow the aproch of :-

1) write the code to perform the task
2) write a wrapper to present the user with a suitable interface

stage 2 could be either a GUI or a CLUE (Command Line User Interface :-) 
) or possibly even both depending on the application.




-- 
An age is called Dark not because the light fails to shine, but because
people refuse to see it.
		-- James Michener, "Space"

[toc] | [prev] | [next] | [standalone]

#48061

I don't normally respond to trolls, but I'll make an exception here.

On 14 June 2013 04:33, Rick Johnson <rantingrickjohnson@gmail.com> wrote:
> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it
>> my way, I'd never write any interfaces again (although
>> designing them is fine). Console interaction is faster to
>> do and it lets me do the stuff I *want* to do quicker.
>
> And are you willing to provide *proof* that the console is
> faster? Or is this merely just your "opinion"? I would be
> ready and willing to compete in a "Pepsi challenge" to
> disprove your claim if needed.  For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program. Are you telling me you can type
> the address faster (much less remember the full path) than i
> can point and click? And if you think you're going to cheat
> by creating an "environment variable", well i can still win
> by doing the same thing with a "shortcut".

1) I said it's faster to implement, not faster to use.
2) Yes, I would win that test. Say I want to go to
"Projects/Programming Tidbits/FeedLess", I'd write "j Fee". Done. I'm
there. What was hard about that?
3) Gee, you think a graphical file manager is good? You should try
Ranger. Seriously, it's way better. (Seriously)

>> Also - Python is pretty much the only language that
>> *isn't* overkill; once you take more than the first few
>> steps a language that's *consistent* will help more with
>> learning, a mon avis, than these "quicker" languages ever
>> will. Python is consistent and simple.
>
> Your statement is an oft cited misconception of the Python
> neophyte. I'm sorry to burst your bubble whilst also raining
> on your parade, but Python is NOT consistent. And the more i
> learn about Python the more i realize just how inconsistent
> the language is. Guido has the correct "base idea", however
> he allowed the evolution to become a train wreck.

If you ignore stdlib, for a moment, lol.
If you include stdlib you're just wrong, but not humorously so.

>> [...]
>> Basically, "kid" is a *very* generic term and there are
>> people who like GUIs and there are people who like
>> internals
>
> Your statement is true however it ignores the elephant in
> the room. You can "prefer" console over GUI all day long but
> that does not negate the fact that GUI's outperform the
> console for many tasks. With the exception of text based
> games, the console is as useful for game programming as a
> cheese grater is for masturbation -- slightly amusing, but
> mostly just painful!

I'd like to see you write or do the equivalent of:
when-changed $FILE.coffee "coffee -c $FILE.coffee; xclip -selection
clipboard < $FILE.js; echo Update"
in a GUI. Really, I would.

Oh, and then make your result searchable with to all of your other
little one-liners, in a process that takes ½ a second to complete.

Nevermind that I was talking about console programs being quicker to
make this whole time, rather than quicker to use.

[toc] | [prev] | [next] | [standalone]

#48067

On Thu, 13 Jun 2013 20:33:40 -0700, Rick Johnson wrote:

> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
> 
>> [...]
>> GUI is boring. I don't give a damn about that. If I had it my way, I'd
>> never write any interfaces again (although designing them is fine).
>> Console interaction is faster to do and it lets me do the stuff I
>> *want* to do quicker.
> 
> And are you willing to provide *proof* that the console is faster? Or is
> this merely just your "opinion"? I would be ready and willing to compete
> in a "Pepsi challenge" to disprove your claim if needed.  For instance,
> if i want to open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the way, and then
> the final double click will open the text file using it's default
> program. Are you telling me you can type the address faster (much less
> remember the full path) than i can point and click? 

If you can remember the full path in order to point and click, then I'm 
sure Joshua can remember the full path in order to type.

And as far as speed goes, well, that depends. If you have three files in 
a directory, which in turn is next two three other subdirectories:

C:
+-- My Documents
+-- My Pictures
+-- My Videos
    +-- amazing movie.avi
    +-- amazing movie.mp4
    +-- amazing movie - the sequel.avi


then, yes, I'm sure you pointing-and-clicking will beat the command line 
to open "amazing movie - the sequal.avi". Trivial tasks like that play to 
the strengths of GUI interfaces.

But, here's a slightly more challenging one: you have to navigate down 
through ten directories, not one. Each directory you navigate through has 
a dozen different subdirectories in it. When you finally reach the bottom-
most directory, where your target video file is, there are two thousand 
other videos in the directory. (Some people's only filing system is "dump 
everything in one place".) None of the video thumbnails are cached, and 
your GUI will helpfully start loading thumbnails as you open the window 
and scroll around. Your "Pepsi Challenge", should you choose to accept 
it, it to find the target file, make a copy of the file in the same 
directory, rename the original, and then open it in an application but 
*not* the default application.

Are you still confident that point-and-click will win this race? I'm 
not... I reckon this would be neck and neck, up to the point where your 
GUI starts loading thumbnails, then the command line will leave you in 
the dust. Even a weak, underpowered command line like command.com (or is 
it cmd.exe? I always forget which is which).

On the other hand... if we don't know the name of the video, and have to 
recognise it by sight, then a GUI has the advantage.

Here's another Pepsi Challenge for you:

There is a certain directory on your system containing 50 text files, and 
50 non-text files. You know the location of the directory. You want to 
locate all the text files in this directory containing the word 
"halibut", then replace the word "halibut" with "trout", but only if the 
file name begins with a vowel.

Still confident that you can do this faster with a GUI than a command 
line interface? I reckon that a full-powered CLI like those available on 
Linux will just about have finished the entire job before you've even 
finished entering information into the GUI search dialog.

But in any case, there are certainly strengths and weaknesses of both 
GUIs and text interfaces, and one should design programs around whichever 
is best for the needs of the program and the user.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#48071

On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Here's another Pepsi Challenge for you:
>
> There is a certain directory on your system containing 50 text files, and
> 50 non-text files. You know the location of the directory. You want to
> locate all the text files in this directory containing the word
> "halibut", then replace the word "halibut" with "trout", but only if the
> file name begins with a vowel.

That sounds extremely contrived, to be honest. Try this one: Massage a
set of MySQL dump files (text, pure SQL) so they can be imported into
PostgreSQL. I'll leave out my Wednesday's encoding headaches (MySQL
produced so-called "UTF-8" output that contained "don\222t" - boggle!)
and restrict this challenge to one thing:

CREATE TABLE blah
(
    blah INT(11) blah blah
);

All through the CREATE TABLE statements, integer fields are followed
by (11), and smallint fields by something else - (9) I think? - and
you have no guarantee that they'll be exactly these numbers, but they
will immediately follow the word INT.

Okay. I can hear some of you screaming "Regular expression!!", and
others yelling "Search across files, any good editor can do that!!". I
happened to use sed for the job. Bear in mind, there are heaps of
other files in the directory, so do this only on *.sql.

Any point-and-click solution to this is likely to end up cheating and
calling on some system that uses text strings (eg regexps). I'd like
to see any solution that proves me wrong, if only out of morbid
curiosity. I'm 100% confident that it won't be faster than me with
sed, or a Perl fanatic with a good regex.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48112

On 2013-06-14 17:21, Chris Angelico wrote:
> On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > Here's another Pepsi Challenge for you:
> >
> > There is a certain directory on your system containing 50 text
> > files, and 50 non-text files. You know the location of the
> > directory. You want to locate all the text files in this
> > directory containing the word "halibut", then replace the word
> > "halibut" with "trout", but only if the file name begins with a
> > vowel.
> 
> That sounds extremely contrived, to be honest.

I've actually done similar, moving sets of media files while renaming
& transforming them (id3v2 to set mp3 tags or modify
filenames/target-directories; exif/convert for .jpg files) along the
way and selecting them, along with container files (select playlists
for MP3s).  Sometimes the media files are named poorly, but better
filename information can be extracted from internal metadata, or can
be combined into things like photo-sets (rather than "DSC314159.JPG",
I can at least have "2013-04-01 Mom's birthday party 314159.jpg"
where the date comes from EXIF data, and a fixed string is replaced.

The idea of operating in batch on any data is pretty much always a
command-line win.

-tim

[toc] | [prev] | [next] | [standalone]

#48165

On Fri, 14 Jun 2013 05:41:20 -0500, Tim Chase wrote:

> On 2013-06-14 17:21, Chris Angelico wrote:
>> On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>> > Here's another Pepsi Challenge for you:
>> >
>> > There is a certain directory on your system containing 50 text files,
>> > and 50 non-text files. You know the location of the directory. You
>> > want to locate all the text files in this directory containing the
>> > word "halibut", then replace the word "halibut" with "trout", but
>> > only if the file name begins with a vowel.
>> 
>> That sounds extremely contrived, to be honest.
> 
> I've actually done similar, moving sets of media files while renaming &
> transforming them (id3v2 to set mp3 tags or modify
> filenames/target-directories; exif/convert for .jpg files) along the way
> and selecting them, along with container files (select playlists for
> MP3s).  Sometimes the media files are named poorly, but better filename
> information can be extracted from internal metadata, or can be combined
> into things like photo-sets (rather than "DSC314159.JPG",
> I can at least have "2013-04-01 Mom's birthday party 314159.jpg" where
> the date comes from EXIF data, and a fixed string is replaced.
> 
> The idea of operating in batch on any data is pretty much always a
> command-line win.
> 
> -tim

interestingly the 1st GUI program i wrote was designed to act as a plugin 
for Thunar, accept a list of photographs & copy then to a new directory 
with options to use exif data as part of the new name 



-- 
Christoph, please remember that irony is not available between the 
Canadian
and Mexican border.... you are confusing them again 8)

	- Alan Cox on linux-kernel

[toc] | [prev] | [next] | [standalone]

#48169

On 2013-06-14, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 13 Jun 2013 20:33:40 -0700, Rick Johnson wrote:
>
>> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>> 
>>> [...]
>>> GUI is boring. I don't give a damn about that. If I had it my way, I'd
>>> never write any interfaces again (although designing them is fine).
>>> Console interaction is faster to do and it lets me do the stuff I
>>> *want* to do quicker.
>> 
>> And are you willing to provide *proof* that the console is faster? Or is
>> this merely just your "opinion"? I would be ready and willing to compete
>> in a "Pepsi challenge" to disprove your claim if needed.  For instance,
>> if i want to open a text file on my machine, i merely navigate to the
>> file via my file browser interface, using clicks along the way, and then
>> the final double click will open the text file using it's default
>> program. Are you telling me you can type the address faster (much less
>> remember the full path) than i can point and click? 
>
> If you can remember the full path in order to point and click,
> then I'm sure Joshua can remember the full path in order to
> type.

My favorite current challenge for an IDE designer is
concatenating text files. This is a one-liner, even with cmd.exe,
but I don't even know how to do it in Explorer. I'd have to use X
number of text editing sessions.

> But in any case, there are certainly strengths and weaknesses
> of both GUIs and text interfaces, and one should design
> programs around whichever is best for the needs of the program
> and the user.

The side issue of keyboard shortcuts in GUI interface have
built-in stengths and weaknesses. I was going to write something
about them earlier, but I got bogged down when I thought of the
issue of accessibilty, which overtakes any such discussion.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#48189

On Sat, Jun 15, 2013 at 2:01 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> My favorite current challenge for an IDE designer is
> concatenating text files. This is a one-liner, even with cmd.exe,
> but I don't even know how to do it in Explorer. I'd have to use X
> number of text editing sessions.

Good point! Or, more generally:

HOW, with a standard point-and-squirt UI, do you invoke one specific
program with two specific data files? Sometimes you can drag two files
onto one program, but usually that involves two separate invocations
of the program, once for each. In theory you could have a concatenator
app, but how do you tell it when you're finished one concatenation and
want to start another? Time delay? Seems clunky and prone to doing the
wrong thing.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48186

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jun 14, 2013 at 3:21 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > Here's another Pepsi Challenge for you:
> >
> > There is a certain directory on your system containing 50 text files, and
> > 50 non-text files. You know the location of the directory. You want to
> > locate all the text files in this directory containing the word
> > "halibut", then replace the word "halibut" with "trout", but only if the
> > file name begins with a vowel.
>
> That sounds extremely contrived, to be honest.


I agree that it sounds contrived, but I've found analogous tasks to be
quite common in the program suite I work on, actually.

We have a set of regression tests for obvious reasons.  To give an order of
magnitude estimate here, there are over 1100 saved test files that get
compared when we run the test suite.

When a change is made to the information reporting (for instance, if we
added a new input variable) or version number that is printed in the output
files, we have ourselves ~2K files.  We then have to scan through all 2K
files (some of which are ASCII, others of which are binary), typically
armed with a regex that identifies the formatting change we just
implemented and change the saved test files (all file names that end in
.save) to the 'new' format. Our task is to find only those files that end
in .save and replace only those files that differ only by the trivial
formatting change to avoid masking a bug in the test suite. [I'm actually
doing this now]

On the whole, it sounds quite similar to Steven's example (only
significantly more files), and is something not even RR could do in a GUI
faster than I can run a script.

[toc] | [prev] | [next] | [standalone]

#48069

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 13, 2013 at 11:33 PM, Rick Johnson <rantingrickjohnson@gmail.com
> wrote:

> On Thursday, June 13, 2013 3:18:57 PM UTC-5, Joshua Landau wrote:
>
> > [...]
> > GUI is boring. I don't give a damn about that. If I had it
> > my way, I'd never write any interfaces again (although
> > designing them is fine). Console interaction is faster to
> > do and it lets me do the stuff I *want* to do quicker.
>
> And are you willing to provide *proof* that the console is
> faster? Or is this merely just your "opinion"? I would be
> ready and willing to compete in a "Pepsi challenge" to
> disprove your claim if needed.  For instance, if i want to
> open a text file on my machine, i merely navigate to the
> file via my file browser interface, using clicks along the
> way, and then the final double click will open the text file
> using it's default program. Are you telling me you can type
> the address faster (much less remember the full path) than i
> can point and click? And if you think you're going to cheat
> by creating an "environment variable", well i can still win
> by doing the same thing with a "shortcut".
>

One of my favorite parts about the Mac over windows, actually, is that I
can open up a console.  Coupled with MacPorts or some other equivalent
package manager, I have what amounts to a working Linux environment
(almost).  The "open" command is particularly useful (equivalent to
double-clicking, with the ability to specify "-a <program name>" to invoke
a right-click->select program->[scan through program list]->click much more
easily.

Coupled with tab completion (as Chris mentioned), and a full history of
visited directories, I can navigate my file system in a console much faster
than I can navigate in the GUI.  It matters little to my productivity how
fast you can navigate a GUI.

But batch processing is, in general, much easier to do in the console in my
experience.  Two tasks I've wanted to do that were of general interest to
computer users (not specifically my work) that I wouldn't have bothered in
a GUI environment:

1) Autocrop a whole bunch of images (~100) to remove extraneous white space
around all of the edges. In the console with imagemagick:

bash$ for image in *.png; do convert $image -trim tmp.png; mv tmp.png
$image; done

2) Compress my library of 2000 jpegs, since I didn't need high-quality
jpegs AND raw images from my camera on my disk consuming space:

bash$ for image in `find . -name "*.jpg"`; do convert $image -quality 70
tmp.jpg; mv tmp.jpg $image; done

Using the console I was able to do both tasks in ~20 seconds quite easily.


> > Also - Python is pretty much the only language that
> > *isn't* overkill; once you take more than the first few
> > steps a language that's *consistent* will help more with
> > learning, a mon avis, than these "quicker" languages ever
> > will. Python is consistent and simple.
>
> Your statement is an oft cited misconception of the Python
> neophyte. I'm sorry to burst your bubble whilst also raining
> on your parade, but Python is NOT consistent. And the more i
> learn about Python the more i realize just how inconsistent
> the language is. Guido has the correct "base idea", however
> he allowed the evolution to become a train wreck.
>

You're right.  NameError's should not be listed with the full traceback
-- the last entry on the call stack is obviously the right way to treat
this special-case exception [1].  BTW, this comment amounts to
Contradiction. [2]

It's sometimes difficult to reconcile several of your comments...


> > [...]
> > Basically, "kid" is a *very* generic term and there are
> > people who like GUIs and there are people who like
> > internals
>
> Your statement is true however it ignores the elephant in
> the room. You can "prefer" console over GUI all day long but
> that does not negate the fact that GUI's outperform the
> console for many tasks. With the exception of text based
> games, the console is as useful for game programming as
> [something not useful]
>

Just because you click through a GUI faster does not mean that everyone
else does, too.

And I've developed some Tkinter-based apps (that you can even download if
you were so interested)---I did all the development on the command-line
using vim and git.

All the best,
Jason

[1] http://mail.python.org/pipermail/python-list/2013-March/642963.html
[2]
https://upload.wikimedia.org/wikipedia/commons/a/a7/Graham%27s_Hierarchy_of_Disagreement1.svg

[toc] | [prev] | [next] | [standalone]

#48229

On Fri, 14 Jun 2013 02:28:29 -0400, Jason Swails
<jason.swails@gmail.com> declaimed the following in
gmane.comp.python.general:


> One of my favorite parts about the Mac over windows, actually, is that I
> can open up a console.  Coupled with MacPorts or some other equivalent
> package manager, I have what amounts to a working Linux environment
> (almost).  The "open" command is particularly useful (equivalent to
> double-clicking, with the ability to specify "-a <program name>" to invoke
> a right-click->select program->[scan through program list]->click much more
> easily.
> 
	While Windows cmd.exe is rather limited (I think my TRSDOS 6 machine
had a more powerful batch language, ignoring the regular command line
[it had a basic debugger that included the ability to do pure sector I/O
on the floppy drives -- including commands to write the directory
sectors which used a different sector type mark]) -- PowerShell has been
available as a download on WinXP and standard on Win7 [PS 3 is a
download for Win7, stock on real Win8].

	While I'm not fluent in it, there are some commands I've gotten
rather engrained...

get-childitem -recurse -filter "*.ad*" | select-string -pattern "with"

finds all the Ada (GNAT convention .ads/.adb) files containing "with"
statements. And pattern probably is a regex so I could fine tune it to
just the package withs by using a start of line marker...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web