Closed MichiK closed 8 years ago
Ok, I just looked at the old speaklater code and did the same here. I agree on the try/catch but I was not really able to decide if this is legit if it occurs and should be catched. Actually, I have seen lazy strings with "<_LazyString broken>" before, but I think in the end it does not really matter since such things are usually only a symptom of another problem.
I work with lazy strings a lot and I have a task that uses them extensively and also produces some logging output containing them. In older versions of Flask Babel, I could simply throw a function's arguments into my logger and get a useful result. E.g. a list of tuples containing some lazy strings looked like this in the logfile:
The same list became this since the update:
Of course, I could wrap
str()
around every lazy string I want to log, but in case of a list, a simplelog(foo)
would becomelog([str(elem) for elem in foo])
.Adding a simple
__repr__
method (like the one of_LazyString
of the old, standalaone speaklater) to theLazyString
class makes life a lot easier here.