LogFile: rename .buffer (to fix newer flask/click)

[obfusk]

Using (custom recipes for) the latest click (7.1.2) and flask (1.1.2) I got an AttributeError: 'str' object has no attribute 'write' because it tries using stdout.buffer.

[obfusk]

Without this change, recent versions of click (which is a dependency of flask) don't work.

[AndreMiras]

I'm concerned it could introduce a regression on sdl2 apps. Or was it backward compatible for a long while?

[obfusk]

I'm concerned it could introduce a regression on sdl2 apps.

I'm not that familiar with those. Why would it introduce a regression?

Or was it backward compatible for a long while?

Was what backward compatible? I'm missing some context here 😅

The problem is caused by the fact that sys.stdout.buffer is normally an _io.BufferedWriter, so the current code is not conforming to the expected interface for sys.stdout (as used by e.g. recent versions of click):

>>> sys.stdout.buffer
<_io.BufferedWriter name='<stdout>'>

According to https://docs.python.org/3/library/sys.html#sys.stderr:

To write or read binary data from/to the standard streams, use the underlying binary buffer object. For example, to write bytes to stdout, use sys.stdout.buffer.write(b'abc').

This has been the case since python 3.0.

[AndreMiras]

It's just that I'm wondering why we see this only now? So I assumed it was a change of behaviour, like new API or something.
If that's the case then updating to the new interface may work for new code but break for old code. It's just suspicion, but I haven't investigated

[obfusk]

It's just that I'm wondering why we see this only now? So I assumed it was a change of behaviour, like new API or something.
If that's the case then updating to the new interface may work for new code but break for old code. It's just suspicion, but I haven't investigated

I investigated a bit. As far as I can tell, click:

• checks for .buffer and assumes it is a binary stream if not None (and uses the original text stream if there's no .buffer)
• detects a LogFile as both "compatible" and "misconfigured" (because it has no .encoding)
• changed the logic (somewhere since version 7.0) and no longer accepts a text stream that is "compatible" but "misconfigured"
• and thus now tries to use the .buffer binary stream because the LogFile is considered "misconfigured"

So I'm not expecting a regression. Not having a .buffer should be the correct fix for old and new versions both.

[AndreMiras]

Thanks for the investigation. Let's merge and we can simply sue you if it breaks something 😄

[AndreMiras]

Thanks