Issue 37141: Allow multiple separators in Stream.readuntil

Text-based protocols sometimes allow a choice of newline separator - I work with one that allows either \r or \n. Unfortunately that doesn't work with StreamReader.readuntil, which only accepts a single separator, so I've had to do some hacky things to obtain lines without having to 

From discussion in issue 32052, it sounded like extending StreamReader.readuntil to support a tuple of separators would be feasible.

Would you make a PR?
I guess to modify Stream.readuntil() 
StreamReader is deprecated, I'm not sure if we should add new functionality to this class.

I wasn't aware of that deprecation - it doesn't seem to be mentioned at https://docs.python.org/3.8/library/asyncio-stream.html. What is the replacement?

Docs will be updated soon.
The change has landed a week ago, I had no time for docs update before 3.8 beta. Sorry for that.

The idea is: StreamReader and StreamWriter are merged into just Stream, open_connection() is replaced with connect() etc.

Ok. Does the new Stream still have a similar interface for readuntil i.e. is this still a relevant request against the new API? I'm happy to let deprecated APIs stay as-is.

Yes, Stream supports all StreamReader and StreamWriter methods

Ok, I've changed the issue title to refer to Stream. Since this would be a new feature, I assume it's off the table for 3.8, but I'll see if I get time to implement a PR in time for 3.9 (and get someone at work to sign off on the contributor agreement, which might be the harder part).

Thanks for the quick and helpful responses.

I finally have permission from my employer to sign the contributors agreement, so I'll take a stab at this when I have some free time (unless nobody else gets to it first).

please do

I've submitted a PR: https://github.com/python/cpython/pull/16429

I already mentioned that in the PR, but we'll have to hit a pause on this.  We decided to revert the latest streams implementation from 3.8, see  https://bugs.python.org/issue38242.  The upshot is that what we have in 3.9 should be more amenable for things like this one.