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

CLI arg typecasting #9

Closed
bitprophet opened this issue Jun 3, 2012 · 2 comments
Closed

CLI arg typecasting #9

bitprophet opened this issue Jun 3, 2012 · 2 comments

Comments

@bitprophet
Copy link
Member

Find a decent way to indicate, on a task or automatically, that e.g. invoke taskname --val=5 should result in a Python value 5 instead of "5", and of course similar for bools, lists etc.

Possibilities:

  • Explicit on the CLI level:

    invoke mytask --wants-an-int int:5 --wants-a-list=list:"a;b;c"
    
  • Explicit on the task declaration level (off the cuff API, but you get the gist):

    @task(argspec={'wants_an_int': int, 'wants_a_list': lambda x: x.split(';')})
    def mytask(wants_an_int, wants_a_list):
        # ...
  • Implicit via conventions, e.g. try/except casting to int and/or float, anything containing semicolons gets split()'d, etc

    • Original ticket said to cast y/yes/etc to booleans, but now that we're using --real --flags booleans happen for free.
    • Would obviously need to be easily toggled, and think about what the default should be
  • Explicit via helper functions -- obviously int/float already exist, so maybe a helper def listarg(x): return x.split(';')

    • Feels kinda dumb unless we can come up with a larger body of useful subroutines worth supporting.

Right now, I'm leaning towards the explicit-at-task-declaration level, with possible implicit-via-conventions. Very torn on whether the implicit should be on by default -- fits the "get stuff done fast" use case but clashes with "don't be surprising".


Was Fabric #69

This was referenced Jun 3, 2012
@bitprophet
Copy link
Member Author

I have a partial implementation of this in master, which infers typing from the default value of arguments (both in terms of a task's argspec, and at the parser level, e.g. if anybody were to construct the parser arguments manually).

Still needs to be expanded to allow something explicit for any args that lack default values.

@bitprophet
Copy link
Member Author

Years-later clarification: the "partial implementation" mentioned above has been a core part of the CLI framework for a long time and seems to work OK for many/most use cases; it's the functionality that knows when you have:

@task
def mytask(c, count=5):
    pass

then this invocation results in count=7 and not count="7":

$ inv mytask --count 7

Combined with boolean true-flags (--bool/--no-bool) and the recently solved #9 for lists (--mylist a --mylist b --mylist c yielding ["a", "b", "c"]) this doesn't leave much but edge cases, which deserve their own ticket(s) anyways.

Things like "no I really want SHORTER ways to supply lists" (can be solved on the user's end with split), dicts (kinda ditto, though we could possibly supply well-tested helpers for parsing eg --mydict=key=val,otherkey=otherval) and etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant