The following code causes an assertion failure in get_encoded_name(), which is
called by _PyImport_LoadDynamicModuleWithSpec() (in Python/importdl.c):

import imp

class BadSpec:
    name = 42
    origin = 'foo'

imp.create_dynamic(BadSpec())

this is because _PyImport_LoadDynamicModuleWithSpec() assumes that spec.name is
a string.

should we fix this (even though imp is deprecated)?

I'm about to go on vacation so I might not be right of mind to comment, but I think throwing a TypeError is valid if it's triggering an assertion error that is already there.

P.S. Thanks for all the fuzz testing you're doing, Oren!

do you mean that we should fix it to raise a TypeError?

the assertion is there, but not explicitly.
get_encoded_name() calls PyUnicode_FindChar(), which calls
PyUnicode_READY(), which does assert(_PyUnicode_CHECK).

so i get:
>>> import imp
>>>
>>> class BadSpec:
...     name = 42
...     origin = 'foo'
...
>>> imp.create_dynamic(BadSpec())
Assertion failed: PyUnicode_Check(op), file ..\Objects\unicodeobject.c, line 380

Yes, I'm saying that instead of hitting the C-level assertion error an explicit TypeError should be raised (or some other change like calling str() on the object). Either way, a C-level assertion from valid Python code is bad. :)

On Thu, Aug 31, 2017 at 1:32 PM, Brett Cannon <report@bugs.python.org> wrote:

I think throwing a TypeError is valid if it's triggering an assertion error that is already there.

+1

P.S. Thanks for all the fuzz testing you're doing, Oren!

Also a big +1. :)

New changeset 9974e1b by Serhiy Storchaka (Oren Milman) in branch 'master':
bpo-31315: Fix an assertion failure in imp.create_dynamic(), when spec.name is not a string. (bpo-3257)
9974e1b

New changeset 99a51d4 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31315: Fix an assertion failure in imp.create_dynamic(), when spec.name is not a string. (GH-3257) (bpo-3653)
99a51d4

Thank you Oren!