On Mon, Jan 10, 2011 at 9:37 PM, Michael Foord firstname.lastname@example.org wrote:
I certainly don't object to fixing this, and neither do I object to adding a new class / module / function attribute to achieve it.
However... is there anything else that this fixes? (Are there more examples "in the wild" where this would help?)
The unittest problem with pickling is real but likely to only affect a very, very small number of users. The introspection problem (getsource) for functools and datetime isn't a real problem because the source code isn't available. If in fact getsource now points to the pure Python version even in the cases where the C versions are being used then "fixing" this seems like a step backwards...
unittest is actually a better example, because there is a solution to your pickling problem: alter __module__ to say "unittest" rather than "unittest.<whatever>", just as _functools.partial and the _datetime classes do. However, you've stated you don't want to do that because it would break introspection. That's a reasonable position to take, so the idea is to make it so you don't have to make that choice. Instead, you'll be able to happily adjust __module__ to make pickling work properly, while introspection will be able to fall back on __impl_module__ to get the correct information.
import inspect from datetime import date inspect.getsource(date) 'class date:\n """Concrete date type.\n\n ...'
import inspect from datetime import date inspect.getsource(date) Traceback (most recent call last): ... IOError: source code not available
With your changes in place would Python 3.3 revert to the 3.1 behaviour here? How is this an advantage?
It's an improvement because the current answer is misleading: that source code is not what is currently running. You can change that source to your heart's content and it will do exactly squat when it comes to changing the interpreter's behaviour.
That said, one of the benefits of this proposal is that we aren't restricted to the either/or behaviour. Since the interpreter will provide both pieces of information, we have plenty of opportunity to make inspect smarter about the situation. (e.g. only looking in __impl_module__ by default, but offering a flag to also check __module__ if no source is available from the implementation module).
What I'm really asking is, is the cure (and the accompanying implementation effort and additional complexity to the Python object model) worse than the disease...
Potentially, but I see enough merit in the idea to follow up with a PEP for it.
-- Nick Coghlan | email@example.com | Brisbane, Australia