Suggestion: If you drop support for older Python, then you can add type hints

[Harding-Stardust]

This will increase the readability and static type checkers such as mypy can be used.

[arizvisa]

This actually violates one of the "mantras" (https://github.com/arizvisa/ida-minsc/wiki/Mantras#object-oriented-programming-and-schemas-suck-due-to-me-having-to-memorize-them-along-with-parameter-order)

The way the entire library is written is so that each function is type-insensitive. This is one of the core concepts of this library and avoids you having to think about types when all you know is that you have a "something" that might be a number, a range, or a name. To give credit, this is inspired from pattern matching that is found in some functional and logic-oriented programming languages.

The idea is due to the fact that most of your reversing artifacts are going to be an integer or a string (perhaps with some metadata attached to it). Hence, the library aims to hide the concept of "types" from you. For example, if you want a function you can reference it by integer, a name, func_t, range_t, area_t, etc. If you want to select a range of addresses, you physically select a range of addresses and then call the function that returns a list of addresses. If you want a type from the type library, you can specify it as a string or an idaapi.tinfo_t that you can retrieved the IDAPython API.

The reason this is done is because most of your good work is going to be confirming things while debugging...which uses addresses and offsets as opposed to some type that you'll need to exchange with another interpreter. If you prefer to use something that is object-oriented and not oriented around functional-programming, there are IDA libraries that actually are type-sensitive. Specifically SynAcktiv's BIP which is more recently maintained, and then there's Sark which was written a little while ago but still actually works (afaik).

Although, I definitely think you should reconsider why you desire type checking for scripting your reverse-engineering tasks. To clarify, I don't mind types...I just don't think they're relevant for all problems. It's probably relevant to note that historically Python figured the same as they decided that it should be done during runtime before adding support for static type checking.

[Harding-Stardust]

So I have basically the same philosophy that the use do not want to know the types but let the code do whatever makes sense. I have however another approach than you that I have code that looks like this:

EvaluateType = Union[str, int, ida_idp.reg_info_t, ida_ua.insn_t, ida_hexrays.cinsn_t, ida_hexrays.cfuncptr_t, ida_funcs.func_t, ida_idaapi.PyIdc_cvt_int64__, idautils.Strings.StringItem]

@typechecked
def address(arg_label_or_address: EvaluateType, arg_debug: bool = False) -> int:
    ''' Takes something and try to resolve it into an address (int) in a smart way.

    Replacement for ida_name.get_name_ea()

    Will always return a valid address or ida_idaapi.BADADDR
    '''
    res = eval_expression(arg_label_or_address, arg_debug=arg_debug) # This function will eval and return an int (None on failure)
    if res is None:
        log_print(f"eval_expression() could not resolve your input in any meaningful value", arg_type="ERROR")
        return ida_idaapi.BADADDR

    if not ida_bytes.is_mapped(res):
        log_print(f"arg_label_or_address (0x{res:x}) is NOT mapped in IDA", arg_type="ERROR")
        return ida_idaapi.BADADDR

    log_print(f"arg_label_or_address resolved to 0x{res:x}", arg_debug)
    return res

This will fulfill the same idea as your multicase but with type hints and I can now do checks that whatever comes into my function address() is something that I can handle.

[arizvisa]

How would you support no parameters or a variable number of parameters when they have differing semantics (where parameters do not neatly consolidate to a single type)? Or to specify differing documentation for each callable where the semantics change depending on the types that they are given? What about when the variable-length'd parameters can take different types and the order matters (done by ins.op_structure)?

With your suggestion, you have to implement each specific case for the function as a conditionals or a structured pattern match. This has the additional effect of scaling up in linear time as you continue to add more cases to your tests. In the end, you actually end up with significantly larger functions in order to support every possible case and logic where the semantics change. I know this because originally that was literally how it was being done 10 years ago (see commit 215d087 for an example). I get that you see

ida-minsc/misc/utils.py

Line 492 in 61dfe40

class multicase(object):

as being complex. The reason it was written this way, however, is algorithmic and it intentionally aims to avoid the aforementioned linear scaling problem.

To elaborate, type hinting is just a parsing feature, it just provides a way to annotate code and fetch information out of the parse-tree during runtime. I don't disagree that type hinting eases readability in certain situations, it's that type hinting doesn't provide anything different from the type-enforcement code that was already written.

[arizvisa]

Probably more relevant to state that I don't like Python enough to rewrite something that already works. Python is a terrible programming language. It's only good bits are that it's better than other languages with regards to embedding it in real software.

[arizvisa]

Converted to discussion.

[Harding-Stardust]

We have the same goal but different paths to get there. It was just a suggestion.

[arizvisa]

Closing this discussion as it seems to be just a coding style disagreement.