Eric Snow added the comment: > Yeah, don't replace any tests, add new ones for the new APIs.
That's what makes the most sense to me too. > Given the > needs of 2/3 compatible loader implementations, the deprecations referred > to in the PEP should also be documentation-only for 3.4. I'm fine with that. I seem to remember one place where an actual deprecation warning would be good, but I'll have to double-check. > A more conservative approach also gives us a chance to make sure we have > provided a full replacement for load_module - it occurred to me after the > PEP was accepted that we may eventually need a "can_load_into(target)" > loader API after all, since loaders may not be finder specific. That means > that with the current API of passing the target to find_spec, I potentially > talked us into repeating the "load_module" mistake on the finder side of > things by asking the finder to handle more than it needed to. Nice analogy. "can_load_into()" makes sense. Do you think it's important enough to include in 3.4? I'm not sure it is, since I'd expect it to be a pretty uncommon case that can be worked around pretty easily (since the finder is fully aware of the loader it's creating). The extra loader method would help with that boilerplate operation, but... As we found out (and you expounded) there are a variety of reload/load-into cases that we could address more explicitly. Perhaps there's a better API that could address those needs more broadly, or maybe they're just not worth addressing specifically. Exploring all this is something that can wait, IMHO. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18864> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
