Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[New Exercise Idea]: using sys.argv #2703

Open
szabgab opened this issue Oct 29, 2021 · 8 comments
Open

[New Exercise Idea]: using sys.argv #2703

szabgab opened this issue Oct 29, 2021 · 8 comments
Labels
discussion 💬 smolder🍲 Lower-priority and/or future idea

Comments

@szabgab
Copy link

szabgab commented Oct 29, 2021

People coming from a GUI-only background will have a lot of fun getting used to the command-line. IMHO it would be a good idea to have them practice. I'd be happy to contribute one or more of my super-simple exercises:

https://code-maven.com/slides/python/exercise-rectangle-argv
https://code-maven.com/slides/python/exercise-calculator-argv

This might require the understanding of lists, though one could explain how to use sys.argv and forward reference to list saying "more detailed explanation will follow".

@github-actions
Copy link
Contributor

🤖   🤖

Hi! 👋🏽 👋 Welcome to the Exercism Python Repo!

Thank you for opening an issue! 🐍  🌈 ✨


  •   If you are requesting support, we will be along shortly to help. (generally within 72 hours, often more quickly).
  •   Found a problem with tests, exercises or something else??  🎉
      We'll take a look as soon as we can & identify what work is needed to fix it. (generally within 72 hours).

​           - If you'd also like to make a PR to fix the issue after discussing it,
             We  💙  PRs that follow our Exercism & Track contributing guidelines!

  •   Here because of an obvious (and small set of) spelling, grammar, or punctuation issues with one exercise,
      concept, or Python document?? 🌟 Please feel free to submit a PR, linking to this issue. 🎉

​        ❗ Please do not run checks on the whole repo & submit a bunch of PRs.
             This creates longer review cycles & exhausts reviewers energy & time.
             It may also conflict with ongoing changes from other contributors.
             For anything complicated or ambiguous, let's discuss things -- we will likely welcome a PR from you.

​        ❗ Please keep in mind that inserting only blank lines, making a closing bracket drop to the next line, changing a
             word to a synonym without obvious reason, adding trailing space that's not a EOL for the very end of text files,
             and other "changes just to change things" are not considered helpful, and will likely be closed by reviewers.


💙  While you are here... If you decide to help out with other open issues, you have our gratitude 🙌 🙌🏽.
Anything tagged with [help wanted] and without [Claimed] is up for grabs.
Comment on the issue and we will reserve it for you. 🌈 ✨

Here to suggest a feature or new exercise?? Hooray! 🎉   Please keep in mind Chesterton's Fence.
Thoughtful suggestions will likely result faster & more enthusiastic responses from maintainers.

@BethanyG
Copy link
Member

sys.argv would be way down the concept tree, so dependancies wouldn't be an issue. And I do think this might be an interesting concept exercise to add. Writing tests for it could be rather involved, but an interesting problem to solve.

However, if the purpose of this would be to get someone used to the command line (not Python), then I would recommend that they do some exercises on the Bash track.

If we're talking the real-world use of Python for configuration scripts and other command-line mini-tools, then yes -- a concept exercise on the sys module in general could be good. But I think we'd need to really have a discussion around what that looked like. We'd also need to figure out how we'd emulate different files systems/trees to cover all scenarios (Mac, Linux, Unix, PC, PC WLS, Mobile....). Given that tests would run in docker (linux -- specifically python 3.9-slim), it could be difficult to test for anything that wasn't dependent on that file system -- which sets up the student for trouble if they aren't using the same setup when coding.

Feels like a better exercise might be one using argparse or click -- which would focus students on writing/thinking through accepting arguments from the command line, but not worrying about OS-specific implementations or parsing.

@J08K -- your thoughts on this? 😄

@BethanyG BethanyG added discussion 💬 smolder🍲 Lower-priority and/or future idea labels Oct 29, 2021
@szabgab
Copy link
Author

szabgab commented Oct 29, 2021

I am not sure I understand why would writing tests be difficult?

$ cat argv.py

import sys

def add():
    return sys.argv[1] + sys.argv[2]
$ cat argv_test.py 

import unittest
import sys

from argv import (
    add,
)

class AddTest(unittest.TestCase):
    def test_add(self):
        sys.argv = ['argv.py', 'hello',  'world']
        self.assertEqual(add(), 'helloworld')

After having one or two exercises with plain sys.argv I'd also think there could be exercises with argparse.

@BethanyG
Copy link
Member

BethanyG commented Oct 29, 2021

https://docs.python.org/3/library/sys.html#sys.argv. Please note the section where it says that the path names are dependent on the file system. This is not about us testing a linux script. This would be about us testing that the student has correctly written code that parses command line arguments.....using their OS.

@J08K
Copy link
Member

J08K commented Oct 29, 2021

So, if you look at the official blurb for the sys library, it says it's system-specific. So for a website with over 750.000 students, it will be quite dangerous to make tests for any OS and that is running on just linux. So, I agree with @BethanyG on that we might want to have a look at argparse, which is in a production standpoint much better to use than argv.

So, almost anything from the sys library is really hard to guarantee to have accurate test results for all students on all platforms.

I do think it can be important for a student to know how to write a proper Command Line Interface, but we might want to put more than a one simple concept in a single exercise, especially so far down the concept tree.

@IsaacG
Copy link
Member

IsaacG commented Oct 29, 2021

Given the plethora of higher level and more modern tools for handling commands and flags, e.g. click, would teaching argparse be the most value for time?

@BethanyG
Copy link
Member

BethanyG commented Oct 29, 2021

The advantage I see with argparse is that it is (somewhat) higher level, and yet still included in the standard lib.

But I agree that click (and possibly fire) are superior. The issue with those is that they are third-party libs. And we could very well include them and make exercises about them....but we should also thoroughly cover the used and useful parts of the standard lib first. And no: I am not advocating for a concept exercise on Turtle 😉 .

That being said -- there are some third-party libs that are just ... really standard. Numpy and its relatives come to mind, as does requests and click. So, it is well worth a thought or two. But we do still have 20+ more basic exercises to get through, so this wouldn't pop to the top of the list for a while yet.

@szabgab
Copy link
Author

szabgab commented Oct 30, 2021

I think as a concept one first needs to understand that the user can put values on the command line that appear as a list in a variable called sys.argv and all the other, higher-level, modules are just processing that list.

As I read the python documentation, it seems to indicate that the content of argv[0] is system-dependent. The rest of values are not. They are just the values that were on the command line.

I think the exercises should focus on that part of the list, argv[1:]

BTW in some other languages, the corresponding variable does not contain the name of program. It only contains the parameters. For example @ARGV in Perl contains argv[1:]

@BethanyG BethanyG changed the title [New Exercises] using sys.argv [New Exercise Idea]: using sys.argv Jun 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion 💬 smolder🍲 Lower-priority and/or future idea
Projects
None yet
Development

No branches or pull requests

4 participants