Voor de volgende code:
logger.debug('message: {}'.format('test'))
pylint
geeft de volgende waarschuwing:
logging-format-interpolation (W1202):
Gebruik %-opmaak in logfuncties en geef de %-parameters door als
argumenten Gebruikt wanneer een logging-instructie de aanroepvorm heeft van
“logging.(format_string.format(format_args…))”. Zo een
oproepen moeten in plaats daarvan % opmaak gebruiken, maar laat interpolatie over aan de
logfunctie door de parameters als argumenten door te geven.
Ik weet dat ik deze waarschuwing kan uitschakelen, maar ik zou het graag willen begrijpen. Ik nam aan dat het gebruik van format()
de beste manier is om instructies in Python 3 af te drukken. Waarom geldt dit niet voor logger-instructies?
Antwoord 1, autoriteit 100%
Het is niet waar voor de logger-instructie, omdat deze afhankelijk is van het voormalige “%”-formaat, zoals string, om luie interpolatie van deze string te bieden met behulp van extra argumenten die aan de logger-aanroep worden gegeven. Bijvoorbeeld in plaats van te doen:
logger.error('oops caused by %s' % exc)
je zou moeten doen
logger.error('oops caused by %s', exc)
dus de string wordt alleen geïnterpoleerd als het bericht daadwerkelijk wordt verzonden.
Je kunt niet profiteren van deze functionaliteit als je .format()
gebruikt.
Volgens de Optimalisatiesectie van de logging
documenten:
Het formatteren van berichtargumenten wordt uitgesteld totdat het niet meer kan worden vermeden. Het berekenen van de argumenten die aan de logmethode worden doorgegeven, kan echter ook duur zijn, en u kunt dit beter vermijden als de logger uw evenement gewoon weggooit.
Antwoord 2, autoriteit 20%
Misschien kunnen deze tijdsverschillenje helpen.
De volgende beschrijving is niet het antwoord op uw vraag, maar het kan mensen helpen.
Als u fstrings (Literal String Interpolation) wilt gebruiken voor logging, dan kunt u dit uitschakelen vanuit het .pylintrc
-bestand met disable=logging-fstring-interpolation
, zie : gerelateerd probleem en opmerking.
U kunt ook logging-format-interpolation
uitschakelen.
Voor pylint 2.4:
Er zijn 3 opties voor het loggen van stijl in het bestand .pylintrc
: old
, new
, fstr
fstr
optie toegevoegd in 2.4en verwijderdin 2.5
Beschrijving uit bestand .pylintrc
(v2.4):
[LOGGING]
# Format style used to check logging format string. `old` means using %
# formatting, `new` is for `{}` formatting,and `fstr` is for f-strings.
logging-format-style=old
voor oud(logging-format-style=old
):
foo = "bar"
self.logger.info("foo: %s", foo)
voor nieuw(logging-format-style=new
):
foo = "bar"
self.logger.info("foo: {}", foo)
# OR
self.logger.info("foo: {foo}", foo=foo)
Opmerking: u kunt niet.format()
gebruiken, zelfs niet als u de optie new
selecteert.
pylint geeft nog steeds dezelfde waarschuwingvoor deze code:
self.logger.info("foo: {}".format(foo)) # W1202
# OR
self.logger.info("foo: {foo}".format(foo=foo)) # W1202
voor fstr(logging-format-style=fstr
):
foo = "bar"
self.logger.info(f"foo: {foo}")
Persoonlijk geef ik de voorkeur aan de fstr-optie vanwege PEP-0498.
Antwoord 3, autoriteit 8%
Naar mijn ervaring is een meer dwingende reden dan optimalisatie (voor de meeste gebruiksgevallen) voor de luie interpolatie dat het goed speelt met logaggregators zoals Sentry.
Overweeg een logbericht met een ‘aangemelde gebruiker’. Als je de gebruiker interpoleert in de format string, heb je net zoveel verschillende logberichten als er gebruikers zijn. Als je op deze manier luie interpolatie gebruikt, kan de logaggregator dit redelijkerwijs interpreteren als hetzelfde logbericht met een heleboel verschillende instanties.
Antwoord 4
Misschien enkele jaren later, maar toen ik hier onlangs mee te maken kreeg, maakte ik het eenvoudig; heb zojuist de string geformatteerd voor de logger.
message = 'message: {}'.format('test')
logger.debug(message)
Op die manier was het niet nodig om de instellingen van het logboek te wijzigen. Als u later naar een normale afdruk wilt overschakelen, hoeft u de opmaak of code niet te wijzigen.