You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
title='Add an implementation of importlib.abc.InspectLoader.get_code'updated_at=<Date2013-05-28.01:15:26.398>user='https://github.com/brettcannon'
I'm contemplating adding an implementation of importlib.abc.InspectLoader.get_code() which relies on get_source() (and then another version in ExecutionLoader which uses get_filename()). The reason I'm hesitant is get_source() is often an expensive operation thanks to having to decode the source code and do a universal newline conversion.
Now I could add the implementation but leave the method abstract, forcing users to make the decision to call super().get_code(), although that's still easy enough that I'm afraid people still won't take into consideration the performance implications.
But maybe I'm worrying too much? We're consenting adults, right? So for that reason I'm leaning towards implementing but leaving abstract with a note in the docs that performance should be considered before just blindly calling the abstract method.
So it turns out I will simply have to make the methods not abstract anymore. Thanks to multiple inheritance I can't implement the method in ExecutionLoader and keep it abstract in case someone subclasses InspectLoader and then creates another subclass of ExecutionLoader and the InspectLoader subclass w/o making ExecutionLoader.get_code not abstract. But if I can't do it there then it seems silly to leave only InspectLoader.get_code abstract.
IOW get_code will not longer be abstract and I will leave a note in the docs to mention you probably want to consider overriding the method for performance.