Update algorithm

[rohaquinlop]

Python let the users make use of list comprehension, this isn't contemplated in the implementation,

[rohaquinlop]

Complexity: 20

def nested_dict(
    *,
    data: IndexedDict,
    keys: list[str] | str,
    keys_node: Node,
    value: Any | None = None,
    value_node: Node | None = None,
) -> None:
    build_key = []

    for _, is_last, key in mark_ends(keys if isinstance(keys, list) else [keys]):
        build_key.append(key)
        data = _nested_dict_handle_list(data)

        if is_last and key in data:
            raise DuplicatedKey(f"Defining a key multiple times is invalid: {key}")

        if key not in data:
            if is_last:
                if key in data:
                    raise DuplicatedKey(
                        f"Defining a key multiple times is invalid: {key}"
                    )
                data[(key, keys_node)] = (
                    value if value is not None else IndexedDict(),
                    value_node or keys_node,
                )
                continue
            data[(key, keys_node)] = (IndexedDict(), value_node or keys_node)
        data = data[key]

[rohaquinlop]

Also, consider the list comprehension cases

[rohaquinlop]

[andrewdea]

Hi @rohaquinlop was this fixed or does it still need some work?
I noticed this behavior in the algorithm:
This snippet gets a complexity of 1:

>>> snippet = """for x in range(0, 10):
    print("even" if x % 2 == 0 else "odd")
"""

>>> cc = code_complexity(snippet)
>>> cc.complexity
1

But this snippet gets a complexity of 3:

>>> snippet = """for x in range(0, 10):
    if x % 2 == 0:
        print("even")
    else:
        print("odd")
"""

>>> cc = code_complexity(snippet)
>>> cc.complexity
3

Is this expected? I could see an argument for treating the inline if-statements as "less complex" but I'm not sure if this was discussed in the paper. Happy to help with this if needed

[rohaquinlop]

At least for me, both must have the same complexity, this is a case that I didn't consider, should we check each parameter of a function call? 🤔

[andrewdea]

yeah I agree with you. I'll take another look at the paper to make sure that is the authors' intent as well.
I think python is particularly tricky here: pretty much any expression could be an inline if-else statement, so I think we'll have to make the algorithm 'dig deeper' into the syntax-tree than it currently does.

[andrewdea]

Hey @rohaquinlop :)
I went back and re-read the paper: I think there is an argument for scoring the inline if-else statement as less complex.
The paper does not explicitly mention this python-specific syntax, and every time they mention an if-else statement they say it should increment the score. However, the first of the three "basic rules" of the score is:

Ignore structures that allow multiple statements to be readably shorthanded into one

The example they provide for this is the null-coalescing operator:

MyObj myObj = a?.myObj;

I'm still leaning towards incrementing inline if-else statements, but thought I'd mention this just so we clarify the implementation

[rohaquinlop]

@andrewdea Then let's keep the current algorithm, I was thinking and isn't normal to nest a lot of expressions in a single inline expression so we can consider it as "no complex". If in the future we find that it is necessary to check this case then we'll add it, what do you think about that?

Also, I think that the new version's release will be today, I'm working to achieve that.

[andrewdea]

@rohaquinlop makes sense to me, let's go with this for now!
It does seem like the authors of the paper left some wiggle-room to interpretation. And as someone who reads quite a bit of python, I'd say that inline statements are generally used in a way that keeps the added complexity to a minimum.

I do think it could be good to add some more documentation to specifically outline the details of our implementation: which statements get an increase in complexity and why. But that's not a very urgent concern.

And thanks so much for working on the release! looking forward to that :)

[andrewdea]

@rohaquinlop should we go ahead and close this issue then?

[rohaquinlop]

@andrewdea I completely forget to announce you that the version 0.5.0 has been released: https://github.com/rohaquinlop/complexipy/releases/tag/0.5.0

[andrewdea]

thanks @rohaquinlop I did see the release 🎉
Looks great and I really like your usability improvements in #52