Brett Cannon added the comment: First, about breaking up _SpecMethods: that was entirely on purpose. =) I honestly have found _SpecMethods a bit of a pain to work with because at every place where I have a spec object and I need to operate on it I end up having to wrap it and then call a method on it instead of simply calling a function (it also doesn't help that spec methods is structured as a collection of methods which can just operate as functions since they almost all have ``spec = self.spec`` at the beginning). I get you're hoping to make PEP 406 happen, but it actually needs to happen first. =) And as I said, the methods are essentially functions anyway so undoing any unraveling I may do won't be difficult to revert if PEP 406 actually comes about. IOW _SpecMethods feels like OOP just 'cause and not for any design reasons; it's been making my eye twitch when I look at that class.
Second, the dance that an advanced user has to worry about is "does create_module exist, and if so did it not return None and if any of that is not true then return what types.ModuleType would give you" is not exactly one line of code ATM. There is no reason to not abstract that out to do the right thing in the face of a loader. Third, yes this would be to encourage people not to directly call types.ModuleType but call the utility function instead. Fourth, I purposefully didn't bifurcate the code of types.ModuleType based on the type of what the first argument was. At best you could change it to take an optional spec as a second argument and use that, but if you did that and the name doesn't match the spec then what? I'm not going to promote passing in a loader because spec_from_loader() cannot necessarily glean all of the same information a hand-crafted spec could if the loader doesn't have every possible introspection method defined (I'm calling "explicit is better than implicit" to back that up). I also don't think any type should depend on importlib having been previously loaded to properly function if it isn't strictly required, so the code would have to be written entirely in C which I just don't want to write. =) Since it's going beyond simply constructing a new module but also initializing it I think it's fine to keeping it in importlib.util which also makes it all more discoverable for people than having to realize tha t types.ModuleType is the place to go to create a module and get its attributes initialized. Fifth, fair enough on not needing the module argument. I will refactor the code for internal use of attribute initialization in testing and leave it at that. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20383> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
