This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brett.cannon
Recipients brett.cannon, favonia, gvanrossum
Date 2021-01-06.18:41:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1609958514.19.0.558132966187.issue42839@roundup.psfhosted.org>
In-reply-to
Content
importlib is probably not os.PathLike-clean due to its bootstrapping restrictions of not getting to use anything implemented in Python from 'os' (i.e. if it isn't being managed in posixmodule.c then it probably won't work).

If you follow the traceback it's trying to marshal a code object for the eventual .pyc file and failing (https://github.com/python/cpython/blob/faf49573963921033c608b4d2f398309d9f0d2b5/Lib/importlib/_bootstrap_external.py#L604). The real question is why is any unmarshallable object getting passed in the first place since that object is the code object that compile() returned.

Best guess? The compile() function is being given the path-like object (via https://github.com/python/cpython/blob/faf49573963921033c608b4d2f398309d9f0d2b5/Lib/importlib/_bootstrap_external.py#L848) and it's blindly setting it on the code object itself, and then marhsal fails since it can't handle pathlib.Path. If my hunch is right, then the possible solutions are:

- Don't do that 😉
- Make compile() aware of path-like objects
- Have importlib explicitly work around compile()'s shortcoming by doing the right thing for path-like objects before passing in the the 'path' argument.
History
Date User Action Args
2021-01-06 18:41:54brett.cannonsetrecipients: + brett.cannon, gvanrossum, favonia
2021-01-06 18:41:54brett.cannonsetmessageid: <1609958514.19.0.558132966187.issue42839@roundup.psfhosted.org>
2021-01-06 18:41:54brett.cannonlinkissue42839 messages
2021-01-06 18:41:54brett.cannoncreate