For example:
>>> 'print 1\n\x0cprint 2\n\n'.splitlines()
['print 1\n', '\x0cprint 2\n', '\n']
>>> list(io.StringIO('print 1\n\x0cprint 2\n\n'))


I'm not sure which is preferable.

Your example got a little messed up.

>>> list(io.StringIO('print 1\n\x0cprint 2\n\n'))
['print 1\n', '\x0cprint 2\n', '\n']
>>> 'print 1\n\x0cprint 2\n\n'.splitlines(True)
['print 1\n', '\x0c', 'print 2\n', '\n']
>>> list(io.StringIO('print 1\x0cprint 2\n\n'))
['print 1\x0cprint 2\n', '\n']
>>> 'print 1\x0cprint 2\n\n'.splitlines(True)
['print 1\x0c', 'print 2\n', '\n']

I think splitlines has it correct.

On the other hand, I believe io is documented as only recognizing /r and /n, so its behavior matches its documentation.

I don't see that, but the chances of changing either of these is quite low, so I suppose we should just document.

"newline controls how universal newlines works (it only applies to text mode). It can be None, '', '\n', '\r', and '\r\n'..."

Whereas splitlines says:

"Return a list of the lines in the string, breaking at line boundaries."

So if we are fixing docs, we need to add that "line boundaries" are based on the relevant unicode properties (see issue 7643).

And, indeed, Antoine has already pronounced on this in issue 6664.

Since this has come up more than once, adding a note that they are not recognized by design in the io module to the io docs might be a good idea.

I think this documentation enhancement was done under issue36642 (PR 12855).

Sorry, I copied the wrong numbers. The doc change is here: https://github.com/python/cpython/commit/8218bd4caf683ee98c450a093bf171dbca6c4849