Re: My son wants me to teach him Python

Discussion in 'Python' started by Joshua Landau, Jun 13, 2013.

  1. On 13 June 2013 17:50, Tomasz Rola <> 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.
    Joshua Landau, Jun 13, 2013
    #1
    1. Advertising

  2. Joshua Landau

    Rick Johnson Guest

    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!
    Rick Johnson, Jun 14, 2013
    #2
    1. Advertising

  3. On Fri, Jun 14, 2013 at 1:33 PM, Rick Johnson
    <> 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
    Chris Angelico, Jun 14, 2013
    #3
  4. On Fri, Jun 14, 2013 at 1:33 PM, 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.


    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
    Chris Angelico, Jun 14, 2013
    #4
  5. I don't normally respond to trolls, but I'll make an exception here.

    On 14 June 2013 04:33, 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? 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.
    Joshua Landau, Jun 14, 2013
    #5
  6. 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
    Steven D'Aprano, Jun 14, 2013
    #6
  7. Joshua Landau

    Jason Swails Guest

    On Thu, Jun 13, 2013 at 11:33 PM, 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? 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's_Hierarchy_of_Disagreement1.svg
    Jason Swails, Jun 14, 2013
    #7
  8. On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
    <> 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
    Chris Angelico, Jun 14, 2013
    #8
  9. Joshua Landau

    Tim Chase Guest

    On 2013-06-14 17:21, Chris Angelico wrote:
    > On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
    > <> 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
    Tim Chase, Jun 14, 2013
    #9
  10. Joshua Landau

    Anssi Saari Guest

    Chris Angelico <> 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?
    Anssi Saari, Jun 14, 2013
    #10
  11. Joshua Landau

    Neil Cerutti Guest

    On 2013-06-14, Steven D'Aprano <> 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
    Neil Cerutti, Jun 14, 2013
    #11
  12. Joshua Landau

    Jason Swails Guest

    On Fri, Jun 14, 2013 at 3:21 AM, Chris Angelico <> wrote:

    > On Fri, Jun 14, 2013 at 4:13 PM, Steven D'Aprano
    > <> 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.
    Jason Swails, Jun 14, 2013
    #12
  13. On Fri, Jun 14, 2013 at 10:02 PM, Anssi Saari <> wrote:
    > Chris Angelico <> 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
    Chris Angelico, Jun 14, 2013
    #13
  14. On Sat, Jun 15, 2013 at 2:01 AM, Neil Cerutti <> 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
    Chris Angelico, Jun 14, 2013
    #14
  15. On Fri, 14 Jun 2013 02:28:29 -0400, Jason Swails
    <> 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
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Jun 15, 2013
    #15
  16. Joshua Landau

    Rick Johnson Guest

    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*
    Rick Johnson, Jun 16, 2013
    #16
  17. On Mon, Jun 17, 2013 at 5:04 AM, Rick Johnson
    <> 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
    Chris Angelico, Jun 16, 2013
    #17
  18. Joshua Landau

    Rick Johnson Guest

    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.
    Rick Johnson, Jun 16, 2013
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. B.julien
    Replies:
    0
    Views:
    394
    B.julien
    Apr 9, 2004
  2. John Ladasky

    My son wants me to teach him Python

    John Ladasky, Jun 12, 2013, in forum: Python
    Replies:
    28
    Views:
    287
  3. Tomasz Rola

    Re: My son wants me to teach him Python

    Tomasz Rola, Jun 13, 2013, in forum: Python
    Replies:
    2
    Views:
    89
  4. Cameron Simpson

    Re: My son wants me to teach him Python

    Cameron Simpson, Jun 16, 2013, in forum: Python
    Replies:
    0
    Views:
    114
    Cameron Simpson
    Jun 16, 2013
  5. Ian Kelly
    Replies:
    0
    Views:
    96
    Ian Kelly
    Jun 17, 2013
Loading...

Share This Page