This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients mitar, rhettinger, sdwarwick, vinay.sajip
Date 2017-09-25.02:35:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1506306923.38.0.424314538408.issue30995@psf.upfronthosting.co.za>
In-reply-to
Content
> logger.info( f" {logger.name:s} {logger.module:s} " ) 
>
> this could be supported with full backward compatibility 
> with very little effort.   
>
> Am I missing something?

One issue is that some of that data isn't known until the logging.info() call is made. And accessing the data before the call would bypass the internal locks, potentially causing race conditions.

Another issue is that having to use an attribute lookup for every variable isn't fast and doesn't look very nice (making this feature awkward to use when the whole goal is to improve usability).

FWIW, you can already use f-strings for all of your local data.  The logging internal data tends to be already set upsteam in the configuration format (which is only done once):

    # Formatting is only done once so %-formatting isn't problematic
    logging.basicConfig(
        level = logging.INFO,
        format = '%(levelname)-8s | %(asctime)s | %(message)s',
        filename = 'demo.log',
    )

    # In the body of the code, use f-strings for your local data:
    logging.info(f'There are {active_users} in {session_name}')
History
Date User Action Args
2017-09-25 02:35:23rhettingersetrecipients: + rhettinger, vinay.sajip, mitar, sdwarwick
2017-09-25 02:35:23rhettingersetmessageid: <1506306923.38.0.424314538408.issue30995@psf.upfronthosting.co.za>
2017-09-25 02:35:23rhettingerlinkissue30995 messages
2017-09-25 02:35:22rhettingercreate