i need a module for more involved command line parsing

[Skaperen]

i am wanting to rewrite this C program into Python3. any suggestions for a module that can handle this kind of command line argument parsing?

Output:
lt2a/forums /home/forums 1> rls -h

rls version 0.9.0

syntax:
        rls  [options]  [names]

single letter options may be combined in a single command line token:
        -0 -1 -2 -3 -4 -5 -6 -7 -8 -9 maximum depth
        -a      append '/' to directory names
        -b      show blocks allocated
        -d -D   show date (-d for local, -D for UTC)
        -g -G   show group name (-G for group number)
        -h -H   show this help and quit
        -i      show inode
        -l      show long format
        -L      show number of links
        -m      show mode
        -n      append nanoseconds to time (if available)
        -N      append nanoseconds to time (if available)
        -p      show where link points to
        -q      output nothing
        -s      show size
        -S      show time/date as raw seconds
        -t -T   show time and date (-t for local, -T for UTC)
        -u -U   show user name (-U for number)
        -V      show version number and quit
        +a      select directories (ascending)
        +b      select block devices
        +c      select character devices
        +d      select directories (descending)
        +h +H   show this help and quit
        +f      select regular files
        +l      select symlinks
        +p      select pipes
        +s      select sockets
        +V      show version number and quit

assignment options must be in separate command line tokens:
        cd=<directory>  change to this directory (multiple)
        maxdepth=<num>  maximum recursion depth

lt2a/forums /home/forums 2>

i'm also thinking about extending the options so they can be changed in the middle of the command line and apply to the names that follow them.

[snippsat]

Click is what i use if making command line interfaces.
Had a short intro here a couple years ago.

[Skaperen]

now i really need to understand decorators and what they do.

[ndc85430]

Essentially, a decorator allows you to put extra behaviour around a function (i.e. before/after it). They do this by returning a new function that does what the original one does but between that extra behaviour (and hence, a decorator is a higher order function).

In Flask, a decorator (Flask.route is used to associate request handling functions with URL paths. The extra behaviour in this case is to basically store that association in a dictionary, so that when a request for a particular path comes in, the correct function can be called. In my codebase at work (albeit in Scala, not Python), we're using the decorator idea to record metrics on the response times in our application.

[snippsat]

now i really need to understand decorators and what they do.

Not really,there is no problem teaching someone Click that don't know what a decorator is.
It's make the interface a lot cleaner eg using @click.command() than have all code make it up in the interface.

It' really the same for most libraries with or without decorator requests.get('https://python-forum.io/').
I do not all need to see the eg 50 lines of code of requests.get() to use it.

A decorator is easy in it's core.

def make_bold(fn):
    '''Do not need to see me'''
    def new_func():
        return f"<b>{fn()}</b>"
    return new_func

User only need to add @make_bold,the name give a hint what it dos or make documentation for it.

@make_bold
def foo():
    return 'python-forum'

print(foo())

Output:
<b>python-forum</b>

[wavic]

Even argparse will do it.

[Skaperen]

now i really need to understand decorators and what they do.

Not really,there is no problem teaching someone Click that don't know what a decorator is.

i'm different than most. i need to understand what i am using/doing. and that needs to understand things as deep as possible. the more i understand it the more i can do with it.

so what does @my_decorator really do?

are decorators always functions? what if some arbitrary function is used?

[snippsat]

so what does @my_decorator really do?

It's not like the web are lacking info about decorators if you search
First hit google Primer on Python Decorators.

In my example with @make_bold,if take away all the magic of @.
It's just functions foo get passed to make_bold function.
make_bold return new_func which added stuff to foo function.

def make_bold(fn):
    '''Do not need to see me'''
    def new_func():
        return f"<b>{fn()}</b>"
    return new_func

def foo():
    return 'python-forum'

make_bold = make_bold(foo) # The cooler way is @make_bold 

The same results.

>>> make_bold()
'<b>python-forum</b>'

are decorators always functions? what if some arbitrary function is used?

No,look at link given.
It's also used in Data Classes.

If you really need to look at source before use Click,then it's all open Click GitHub

[DeaD_EyE]

To understand a decorator, you have to understand what a closure is.

def function(a):
    b = 40
    def inner_function():
        print(a,b)
    inner_function()  # <-- calls the inner_function
    # inner function has access to the scope of function

If you rewrite the inner_function as anonymous lambda function, it's more clear:

def function(a):
    b = 40
    inner_function = lambda: print(a, b)
    inner_function()  # <-- calls the inner_function
    # inner function has access to the scope of function

Decorators should take a function and modify the behavior (input_values, return_values).
This can be reached with a closure, which returns the inner function.

def square(function):
    def inner(*args, **kwargs):
        return function(*args, **kwargs) ** 2
    return inner # <- returns the inner function without calling it


def foo():
    return 42


print(foo())
# the direct call together with the decorator looks like this
square(foo)()  # <- square(foo) returns inner, inner is called
# assign the decorated function to a name
square_foo = square(foo) # square_foo is now the function inner
# calling square_foo
square_foo()

To @ sign for the decorator is just a syntactical sugar for us.

@wrapper
def func():
    return

# is the same like
def func():
    return
func = wrapper(func)
# old name is overwritten by inner function

[Skaperen]

Even argparse will do it.

can it handle the + options, too?

---

To @ sign for the decorator is just a syntactical sugar for us.

@wrapper
def func():
    return

# is the same like
def func():
    return
func = wrapper(func)
# old name is overwritten by inner function

decorating func with wrapper causes all calls to func to go through wrapper first, passing a reference to the original func? if yes, how does it deal with arguments? i have seen decorators that have arguments and, of course, the function can be called with arguments.

let me see if i got it:

when we create/define a function with def it creates the function code (named, unlike lambda), a reference to that function, and assigns the reference value to the name in that namespace. but, a decorator ahead of a def changes that to creates a wrapper function that calls the function referred to after the @, passing it a reference to the function created by the def. presumably, the function referred to after the @ will, in some way, call that function (the one it got a reference to), get its return result, maybe modify it, and return that to the original caller. a reference to the wrapper function is the function reference value assigned to the name in the def statement in place of the code that follows the def statement.

did i get that right?

i think i still need to understand how the 2 bunches of arguments are handled.

1. the arguments expressed on the @ line (and which namespace are the names looked up in).
   
2. the arguments given by the caller.
   

i have also seen code where 3 lines of @ decorators are over one def statement. i'll need to understand that, too.

i really am the kind of person that needs to understand how things work. i remember being exposed to 3 higher level programming languages, first. in my mind, i formed a very complex idea of how computers were built. then i learned about compilers and machine code. while on a family vacation to the beach, and visiting a college book store along the way, i found a book about assembly language for the IBM mainframe. this was in 1972. i spent the whole week reading that entire book. assembly language and machine language finally made computers "click" for me.