the following causes an assertion failure in Python/_warnings.c in
show_warning():

import warnings

class BadLoader:
    def get_source(self, fullname):
        class BadSource:
            def splitlines(self):
                return [42]
        return BadSource()

del warnings._showwarnmsg
warnings.warn_explicit(message='foo', category=ArithmeticError, filename='bar',
lineno=1, module_globals={'__loader__': BadLoader(),
'__name__': 'foobar'})

in short, the assertion failure would happen in warnings.warn_explicit() in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1]
is not a str.

the following raises a SystemError:

import warnings

class BadLoader:
    def get_source(self, fullname):
        class BadSource:
            def splitlines(self):
                return 42
        return BadSource()

warnings.warn_explicit(message='foo', category=UserWarning, filename='bar',
lineno=42, module_globals={'__loader__': BadLoader(),
'__name__': 'foobar'})

in short, warnings.warn_explicit() raises the SystemError in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()
is not a list.

ISTM that adding a check in warnings_warn_explicit() (in Python/_warnings.c),
to check whether
module_globals['__loader__'].get_source(module_globals['__name__'])
is a str (after existing code found out that it isn't None) would prevent both
the assertion failure and the SystemError.

What do you think? Is it OK to permit get_source() to return only None or a str?

on a second thought, BadSource could be a subclass of str, so maybe we
should just check whether
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1]
is a str,
and whether
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()
is a list.

An alternative solution is using str.splitlines(source) instead of source.splitlines(). It raises a TypeError if the argument is not a text string and always returns a list of strings.

According to the documentation get_source() must return a text string or None.

https://docs.python.org/3/library/importlib.html?highlight=get_source#importlib.abc.InspectLoader.get_source

ISTM that your solution is better than mine, Serhiy, so I updated the PR.

New changeset 91fb0af by Serhiy Storchaka (Oren Milman) in branch 'master':
bpo-31285: Fix an assertion failure and a SystemError in warnings.warn_explicit. (bpo-3219)
91fb0af

New changeset 90fe25a by Serhiy Storchaka in branch '3.6':
[3.6] bpo-31285: Fix an assertion failure and a SystemError in warnings.warn_explicit. (GH-3219) (bpo-3775)
90fe25a

PyUnicode_Splitlines() cannot be used here in 2.7, because the source is likely a 8-bit string.

Actually I'm not sure this issue is worth to be fixed in 2.7. The fix would be different from 3.x and more complex.

In 2.7, PyUnicode_Splitlines() first does:
string = PyUnicode_FromObject(string);

So i thought that PyUnicode_Splitlines() would be fine with receiving a string.

But now i realize that even in case i was right there, PyUnicode_Splitlines()
returns a unicode, and not a string, so there should be problems later.
I wonder how the tests still passed..

In 2.7, PyUnicode_Splitlines() first does:
string = PyUnicode_FromObject(string);

And it raises an exception if the string contains non-ASCII characters.

It is better to avoid str<->unicode convertion as long as possible. And when
do it for the output a warning, use "replace" or "backslashreplace" error
handlers or "latin1" decoder to avoid a failure.

Another thought - the existing code assumes that splitlines() returned a string.
So maybe we could just check that get_source() returned a string, and then call
the method str.splitlines() on it?

oh, of course, checking that get_source() returned a string before passing it to
str.splitlines() is not needed.

What if get_source() returned a unicode string? Usually it returns 8-bit string, but in many cases unicode is accepted if str is expected, so you need to check this option too.

But in case get_source() returned a unicode, is it likely that the splitlines() method
of this unicode would return a 8-bit string? Currently show_warning() doesn't handle this
scenario, as it assumes splitlines() returned an 8-bit string. Or do you think that
show_warning() should also accept unicode?

I didn't check. I supposed that the other code can support unicode by
implicitly converting it to str. But now I see that show_warning() uses
PyString_AS_STRING() and therefore supports only str. I agree, using
str.splitlines() would be correct solution.

New changeset 8b4ff53 by Serhiy Storchaka (Oren Milman) in branch 'master':
bpo-31285: Remove splitlines identifier from Python/_warnings.c (bpo-3803)
8b4ff53

I just missed PR 3803.

New changeset 66c2b9f by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31285: Remove splitlines identifier from Python/_warnings.c (GH-3803) (bpo-3829)
66c2b9f

New changeset 40d736b by Serhiy Storchaka (Oren Milman) in branch '2.7':
[2.7] bpo-31285: Don't raise a SystemError in warnings.warn_explicit() in case __loader__.get_source() has a bad splitlines() method. (GH-3219) (bpo-3823)
40d736b