Thursday, March 15, 2018

Being Too Pythonic'y and Enterprise Level Coding and Code Personalities

I recently had to change a piece of code from this …


return [convert_thing(k,v) for k, v in get_things()]

To …

things = []
for k, v in get_things():
    try:
        thing = convert_thing(k,v)
        things.append( thing )
    except Exception as ex:
        logger.error(ex)
return things

Why would I convert this beautiful pythonic'y piece of code to a crude almost straight C version? Because it turned out convert_thing() could raise an exception if it could not convert the thing and there is no pythonic'y way I know of to do this.

On a second note, it would be nice if we could overtly recognize the concept of code personality. When a larger system (or framework if you prefer) is constructed it is often the case that with some configuration modifications it can perform various related functions. A simple example would be if we built a program to convert and transfer a file and then used it to convert CSV files to JSON for one deployment and then used the same code (with configuration changes) to convert a file from XML to CSV for a second deployment. It would be nice if we could refer to the two different deployments by personality (xfer_hr versus xfer_money_orders) which would ultimately refer to the same piece of code.

You can always do this using simple configuration files (which could be something a personality pre-processor could do automatically) but it adds a level of complexity which is unnecessary if code had a way of universally expressing its personality. It is always a good idea to reduce the level of configuration nesting.