Support with statements - #120

On first glance this doesn't seem to be in line with the intended use of with statements, which is factoring out standard uses of try/except/finally.

The code in included unit tests doesn't throw any exceptions. Although __exit__ should return a boolean value, both the default function and the one included in the test return None -- which means any exception caught by the with block will always be re-thrown. I.e. __exit__ is here used purely for side-effect, and not to decide whether to re-raise the exception.

The example in the README:

with TabulateContextManager() as t:
    t("Bill", 25)
    t("Mary", 26)

is roughly equivalent to:

try: 
    rows = []
    rows.append("Bill", 25)
    rows.append("Mary", 26)
except:
    raise
finally:
    print(tabulate(rows))

I suggest reading through PEP-0343 and reconsidering if the above is really a common use case for users of this library. Is your use case really that on exceptions while adding rows you want to print whatever made its way into the table data and then re-throw exception? Because this is what the code in this PR does, albeit through use of syntactic sugar.

If your use case is really this:

    rows = []
    rows.append("Bill", 25)
    rows.append("Mary", 26)
    print(tabulate(rows))

then it is IMHO a use case where there's no need for context management (that array with data in the example can reside in whatever context programmer wants it in, e.g. the scope of a function or in some object) and exception handling (non-existent in the example, so there's nothing for the wtih block to factor out), and so the with block doesn't add any value. On the contrary, it could make the code (especially the exception handling part) harder to understand.

TBH I was only looking after the "syntactic sugar" part. I agree with your concerns and that this "feature" is not important. Please feel free to close this PR if you want.

Thank you @kbairak for confirming, glad that we could get on the same page.

@astanin I do recommend closing this PR to avoid "feature creep".

I agree with you that it is feature creep at the moment, and it goes against "Explicit is better than implicit" principle.