Andrew Clegg <andrew.cl...@durham.ac.uk> added the comment:

I meant the former; I'll look a bit more at the documentation and submit an 
issue/patch.

As regards the 'text' flag - universal_newlines is actually exactly that 
already. I've just checked the code of subprocess.py and the universal_newlines 
argument is read in only two places:
* as one of the deciding factors in whether to use the text mode
* in a backwards compatibility clause in check_output

So subprocess *already* has a text mode and a 'magic option' to trigger it. It 
works well, and is useful in most cases. When the default encoding guess is 
incorrect, it can easily be corrected by supplying the correct encoding. This 
is a good situation!

What is not so good is the API. I'm teaching a Python course for scientists at 
the moment. Retrieving text from external processes is an extremely common use 
case. I would rather not teach them to just have to use 'encoding=utf-8', 
because arguably teaching a user to supply an encoding without knowing if it's 
correct is worse than the system guessing. Equally, teaching 
'universal_newlines=True' is a bit obscure.

The way forward seems to be:
* Add a text=True/False argument that is essentially the same as 
universal_newlines, to improve the API.
* Clearly document that this implies that the encoding will be guessed, and 
that an explicit encoding can be given if the guess is wrong
* Optionally, and I have no strong feelings either way on this, 
remove/deprecate the universal_newlines argument

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue6135>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to