Re: String formatting

2016-10-26 Thread Li Xuan Ji
I vote for sticking with logging's format `logging.info("Some message with a param: %s", param)` because it has less parentheses :) On 26 October 2016 at 20:40, Maxime Beauchemin wrote: > The history here is we started the project with Flake8 / PEP8 and > eventually turned on PyLint through Lan

Re: String formatting

2016-10-26 Thread Maxime Beauchemin
The history here is we started the project with Flake8 / PEP8 and eventually turned on PyLint through Landscape (which has been a nice service, but is often down, not picking up our PRs) Unless I'm missing something I think the cost of formatting strings that may not get logged is most likely pret

Re: String formatting

2016-10-26 Thread George Leslie-Waksman
There are a few layers of things going on here. The first, and the reason for the landscape warning, is that logger performs string formatting lazily and doing the formatting explicitly results in extra processing for log levels that are being ignored. The second is that the logger can be configu

Re: String formatting

2016-10-17 Thread Andrew Phillips
My understanding from the latest python documentation is that '.format' supersedes the use of '%'. Therefore, it seemed a little strange that the Landscape configuration was advising the use of '%', I think the thing here is that the "%" that the warning is talking about is *not* the same oper

Re: String formatting

2016-10-17 Thread Maycock, Luke
5:23 To: dev@airflow.incubator.apache.org Cc: Maycock, Luke Subject: Re: String formatting Indeed -- though I think the larger question from Luke is whether or not we want to enforce a certain style of logging message (variable arguments vs formatting the string itself). Since there's nothin

Re: String formatting

2016-10-17 Thread Jeremiah Lowin
Indeed -- though I think the larger question from Luke is whether or not we want to enforce a certain style of logging message (variable arguments vs formatting the string itself). Since there's nothing to stop users from formatting the string on one line and passing it to logging on the next, not

Re: String formatting

2016-10-17 Thread Andrew Phillips
Perhaps I stand corrected! -- though I don't see where it actually says this approach is preferred. In any case, the Python 3 docs explicitly state that the behavior is only maintained for backwards compatibility: https://docs.python.org/3/howto/logging.html#logging-variable-data Ah, interesti

Re: String formatting

2016-10-17 Thread Jeremiah Lowin
Perhaps I stand corrected! -- though I don't see where it actually says this approach is preferred. In any case, the Python 3 docs explicitly state that the behavior is only maintained for backwards compatibility: https://docs.python.org/3/howto/logging.html#logging-variable-data On Mon, Oct 17,

Re: String formatting

2016-10-17 Thread Jeremiah Lowin
Good question. Personally I hate this warning, I like new-style formatting far more than "%"-style formatting (and in fact, what pylint wants is neither -- it prefers something like `logging.info('my msg is %', my_msg)`). The stated reason ( https://bitbucket.org/logilab/pylint/pull-requests/169/ad

Re: String formatting

2016-10-17 Thread Andrew Phillips
"Use % formatting in logging functions and pass the % parameters as arguments" [...] Can anybody give a judgement on this? If the .format is preferred, then we'll look into changing the landscape.io settings. As far as I can tell from the Python 2 logging docs [1] at least, the following is