haaconcierge.blogg.se

1. WHEN POSSIBLE USE THE DEFAULT TEXT ENCODING IN REPLIES PATCH
2. WHEN POSSIBLE USE THE DEFAULT TEXT ENCODING IN REPLIES WINDOWS

Per a serialization handler, I looked at the 2 issues you mentioned and my monkey-patching is pretty similar.

WHEN POSSIBLE USE THE DEFAULT TEXT ENCODING IN REPLIES WINDOWS

You are correct that the 'invalid json' is really me stringifying/making JSON on a windows machine and parsing it on a linux machine. It is perfectly possible to invoke orjson using the format argument, while avoiding having to monkeypatch the OH NO! I thought I had responded and I did not! Sorry for the delay! :/ I prefer that the serialize option remains a dump boolean. I am not convinced that such a change is necessary. This is a suggestion that came up several times ( #278, #203). We just need to make sure to bump the Loguru version to v0.6.0 as it's a possible breaking change for Windows users. Worse, this error may occur even without serialization if someone writes a message with an unsupported character. Otherwise, an UnicodeEncodeError will be raised. It means if locale.getpreferredencoding() returns cp1252 then an handler with serialize=True can't write to a file sink except if encoding="utf8" is explicitly specified by the user.

Actually it will be much better to default to utf8 because of the emoji-icon you mentioned. Unless if someone tries to read the file using a different encoding than the one used by loguru (say for example utf8 instead of the one returned by locale.getpreferredencoding()). It also creates technically invalid JSON (tho it works with the stdlib json parser/serializer).įor my information, can you please explain me how this can lead to the creation of an invalid JSON? However, it is true that if serialize=True there is no choice anyway. That's why there is no in the default format. I think you kinda have made the decision already tho by including emoji-icon things that don't render on my windows machine.Īlthough such symbols were not mean to be displayed if sink does not support unicode, be it a file or the console. Unrelated: I was thinking of opening a pull request if/when I find the time to allow the serialize option for a sink to be either a bool or a callable that accepts (test, record) and returns a string. The PEP discussion you link to is pretty interesting, but I don't think the reasons they mention for not making the default encoding utf8 (that some windows users just want to do their job and not delve into the oddities of file encodings) apply to the average lo-guru. The only thing I have to do is set the encoding of the file sink to make this work on windows. Both libs are faster than the stdlib json-module AND are stricter about sticking to creating valid JSON.

WHEN POSSIBLE USE THE DEFAULT TEXT ENCODING IN REPLIES PATCH

I have several scripts that use loguru but monkey patch in a new def _serialize_record(text, record): that uses orjson/python-rapidjson. It also creates technically invalid JSON (tho it works with the stdlib json parser/serializer). I think you kinda have made the decision already tho by including emoji-icon things that don't render on my windows machine.