wrrulos / easyjsonpy

Python library that allows you to easily load languages and settings ​​into your project using JSON files

Hola 👋

Soy un programador de Argentina 🇦🇷🐍

Stats

Languages

easyjsonpy's Issues

High execution times when getting values for very long lists of keys

Hello, I've found a small problem in the code. The affected methods are src.easyjsonpy.config_loader.ConfigLoader.get_config and src.easyjsonpy.lang_loader.LangLoader.get_message. The problem is in the combination of the lambda expression with the reduce function. Imagine there is a dict like {'x': 1} and a list (of keys) with length of 10,000,000 or more containing keys of which one or more do not exist in the dict or nested dicts (for example ['y', 'x', 'x', 'x', ... 'x']). The reduce function calls the lambda expression as many times as many keys are in the list. It looks like this:

def reduce(function, sequence, initial=_initial_missing):
    it = iter(sequence)

    if initial is _initial_missing:
        try:
            value = next(it)
        except StopIteration:
            raise TypeError(
                "reduce() of empty iterable with no initial value") from None
    else:
        value = initial

    for element in it:
        value = function(value, element)

    return value

Even if the very first lambda call returned None, the function would still call the lambda expression 9,999,999 more times before the actual method get_config or get_message returns the final value (None), because the isinstance check in the lambda expression does not really stop the loop but only returns None and reduce function's loop just goes on (the isinstance check would have to be placed in the reduce function's loop). This is making the getting process take multiple seconds to finish with very long lists of keys (the more keys are in the list, the higher the time is), which is unnecessarily long and very inefficient for such a small dict. I know this only has a minimal impact as most likely no one will use such long lists of keys in practice, but I think this should be improved anyways.

Thanks!