Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-265

Support Python string formatting method in logging

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None
    • Location:
      on this ticket

      Description

      Python has two (3 in python 3.6) ways of formatting a string for output. The log package currently assumes that %-style formatting is being used for all log output but in some cases it is more convenient to use the format method style instead.

      The proposal is that we add new logging methods, for example debugf and infof, that assume format-method formatting. This formatting will be applied internally at the python layer if the log message is to be written as is done now for %-style formatting.

      We have discounted a "magic" approach of checking the logging string for curly braces or percent symbols. We have also discounted migrating the entire stack to use format for logging as python seems perfectly happy to have 2 (3) styles itself.

        Attachments

          Issue Links

            Activity

            Hide
            Parejkoj John Parejko added a comment -

            Good point about deferred formatting, I hadn't considered that. That said, using the appended-f names seems very clunky to me, but I don't know what a better option would be.

            Show
            Parejkoj John Parejko added a comment - Good point about deferred formatting, I hadn't considered that. That said, using the appended-f names seems very clunky to me, but I don't know what a better option would be.
            Hide
            salnikov Andy Salnikov added a comment -

            I proposed more explicit and cleaner style log.info.format(...) (keeping also existing log.info(...)) but it is 6 character longer than a single appended "f".

            Another wild idea would be to try to generalize current log methods to accept broader class of arguments, for example we could pass any callable as a first argument and call it later with remaining arguments to produce a message. Then we can do something like:

                # if first argument is a callable then call it with remaining args
                log.info("x={:.3f} y={:.3f}".format, x, y)
             
                # if first argument is a string then use % interpolation
                log.info("x=%.3f y=%.3f", x, y)
            

            I know this trailing .format looks ridiculous, not sure if this can be improved though while keeping it generic enough.

            Show
            salnikov Andy Salnikov added a comment - I proposed more explicit and cleaner style log.info.format(...) (keeping also existing log.info(...) ) but it is 6 character longer than a single appended "f". Another wild idea would be to try to generalize current log methods to accept broader class of arguments, for example we could pass any callable as a first argument and call it later with remaining arguments to produce a message. Then we can do something like: # if first argument is a callable then call it with remaining args log.info( "x={:.3f} y={:.3f}" . format , x, y)   # if first argument is a string then use % interpolation log.info( "x=%.3f y=%.3f" , x, y) I know this trailing .format looks ridiculous, not sure if this can be improved though while keeping it generic enough.
            Hide
            tjenness Tim Jenness added a comment -

            I think I'm inclined to stick with infof() as it's less typing. Adding the callable interface could be done any time, and you could implement infof using that exact scheme (so essentially making infof syntactic sugar).

            Show
            tjenness Tim Jenness added a comment - I think I'm inclined to stick with infof() as it's less typing. Adding the callable interface could be done any time, and you could implement infof using that exact scheme (so essentially making infof syntactic sugar).
            Hide
            tjenness Tim Jenness added a comment -

            If no-one objects I am going to adopt this RFC in a day or two and go with the f suffix option.

            Show
            tjenness Tim Jenness added a comment - If no-one objects I am going to adopt this RFC in a day or two and go with the f suffix option.
            Hide
            tjenness Tim Jenness added a comment -

            As promised, I'm adopting this proposal to allow us to use str.format in log messages.

            Show
            tjenness Tim Jenness added a comment - As promised, I'm adopting this proposal to allow us to use str.format in log messages.

              People

              • Assignee:
                tjenness Tim Jenness
                Reporter:
                tjenness Tim Jenness
                Watchers:
                Andy Salnikov, Hsin-Fang Chiang, Jim Bosch, John Parejko, John Swinbank, Kian-Tat Lim, Mario Juric, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel