'AnsiTerm' object has no attribute 'buffer'

[Fred Wright]

On Tue, 29 Jan 2019, Gary E. Miller via devel wrote:
> On Tue, 29 Jan 2019 19:01:40 -0800 (PST)
> Fred Wright via devel <devel at ntpsec.org> wrote:
>
>>> Well, the way we use sys.stdout is warned about in the Python doc.
>>> That is enough for me to want it aligned with the python doc.
>>
>> The real question is why the build procedure thinks it needs to
>> output 'bytes' to the terminal,
>
> Easy, to fix make the code work with Python2 and Python 3.
>
> See here:
>
> https://gitlab.com/esr/practical-python-porting/blob/master/polystr-inclusion.py
> http://www.catb.org/esr/faqs/practical-python-porting/
>
> Weird, but no one has done better.

Yes, I'm familiar with that, having done some of the Python3 work on GPSD. 
:-)

But the only reason to use make_std_wrapper() is when something might be 
talking to stdio in 'bytes' rather than 'str'.  If all stdio is with 'str' 
then the wrapper is unnecessary, with any version of Python.  If the 
*build procedure* is using 'bytes' with the terminal, then that almost 
certainly means that something else is broken, and should probably be 
fixed, rather than applying the troublesome wrapper.

However, it appears that the real problem is that polystr-inclusion.py is 
broken in that it *unconditionally* applies make_std_wrapper() to the 
stdio streams, regardless of whether it's necessary or permitted.

>> It can probably be worked around by prefixing the build command with
>> "NOSYNC=1", which disables waf's AnsiTerm hackery.
>
> That worked.  Thanks!
>
> Something for Eric to add to the INSTALL procedure and to his 'Practical
> Python Porting".

Probably not, since it's specific to the misuse of the polyglot hacks with 
waf (or perhaps other things that override the standard Python stdio).

BTW, it's highly useful when debugging waf code with pdb, since waf's 
AnsiTerm breaks the readline stuff.  That's how I knew about it. :-)

On Wed, 30 Jan 2019, Matthew Selsky via devel wrote:
>
> Is this a waf bug, or a 'Practical Python Porting' bug?

The latter, as noted above.  The make_std_wrapper() hack is never 
guaranteed to work with third-party replacements for the stdio streams, so 
applying it unconditionally is asking for trouble.

As to why it just started happening recently, I have no idea.

Fred Wright