The cloud-native orchestrator for the whole development lifecycle, with integrated lineage and observability.

dagster

hi again, does the dagster logger allow lazy logging?  it doesn't like having extra args for string formatting in the way the normal python logger does e.g. `<http://log.info|log.info>("the next train is at %s", never)`

this would be a reasonable feature request but might require us to rethink the way that logging works; right now log level is really just a filter that dagit, etc., uses to decide which messages to display

all of the messages are generated and stored though

mm, i could be wrong, actually, it might be easy to implement

`<http://log.info|log.info>(f"the next train is at {never}")`

f strings aren't lazily evaluated though and errors in the string formatting are handled differently.  a colleague has also had issues with log aggregation when log statements have f-strings though i have no experience with that
<https://medium.com/swlh/why-it-matters-how-you-log-in-python-1a1085851205>

Not sure what you mean by lazy evaluation then

sorry, i have an appointment with some wine so I will come back to this on monday!

hah <@U018ELQ343U> in this case lazy evaluation just refers to the fact that IF relying on the inbuilt logging module - like <@U018LFS86KF> posted in the original post - string formatting only happens if the logging level is hit - i.e. if you have very many DEBUG logs but your log level is INFO or WARNING etc, the DEBUG logs' strings won't get formatted.

However if you format the string yourself, e.g. by using an f-string or `"something %s this" % "like"` then formatting happens when the execution goes over that line of code, whether or not it actually logs

You mean re: delaying the call to __str__?

But not usually saving a lot of time :slightly_smiling_face:

And that couldn't really work with dagit since the level selector happens so much later, off in javascript