Regardless of the value of `encoding`, StreamReaders returned for the `asyncio.subprocess.Process`'s `stdout` and `stderr` would be in binary mode.

    import sys
    import asyncio
    import subprocess

    async def main():
        sp = await asyncio.create_subprocess_exec('ls', '-la',
                                                  stdin=None,
                                                  stdout=subprocess.PIPE,
                                                  encoding='utf8')
        await sp.wait()
        data = await sp.stdout.read()
        print(data)
        print(isinstance(data, bytes))

    loop = asyncio.get_event_loop()
    loop.run_until_complete(main())

There are two naive solutions:

- `create_subprocess_*` could explicitly raise when provided any `encoding` and `errors` (like it now does with `universal_newlines`).

- or implement encoding conversions for StreamReaders (and StreamWriters), and forward those.

Of course it would be better to have conversions, but I don't know how those will have to deal with decoding partially available data - e.g. returning in the middle of surrogate pair, or having only half a codepoint for UTF16. There should likely cache partial data to process at the next read, but this would require rewriting codecs to support partial decode... seems like it's not that easy :(

I'd love to see universal_newlines=True in asyncio.subprocess.

Python's codecs already support partial decode, exactly to handle this kind of case. See codecs.getincremental{en,de}coder and

https://docs.python.org/3/library/codecs.html#incremental-encoding-and-decoding

It occurs both on Python 3.6 and 3.7 RC, so maybe it should be fixed in the 3.7 release.

@adampl: The first step is for someone (possibly you :-)) to write a patch and submit it as a PR against the Python master branch. Then once the actual change is figured out, we can have the discussion about which releases to backport it to.

After reading the docs more carefully, it's now plain to me that text encoding is not supported yet, so actually it's not a bug :)

However the docs should be improved (and then an assertion could be added too) to prevent people from falling into this trap. Only the `universal_newlines` parameter is explicitly mentioned, while others (including `encoding` and `errors``) are passed to `subprocess.Popen`, which falsely suggests that they should work fine. Moreover, the `std*` properties of the subprocess have a `_transport._pipe.encoding` set to the encoding passed to `asyncio.create_subprocess_*`, but apparently it's not used at all. IMHO this is too messy.

Alternatively this option could be implemented, which would require a new kind of StreamReader and StreamWriter.

encoding was explicitly disabled by #36686
Now its usage generates ValueError.

asyncio stdio/stdout/stderr streams are bytes.
If you want to propose a patch that supports text streams -- please create another issue for that.