On 01/10/2011 05:26 AM, Nick Coghlan wrote:
On Mon, Jan 10, 2011 at 11:11 AM, Ron Adamrrr@ronadam.com wrote:
On the python side of things, the attributes we've been discussing almost never have anything to do with what most programs are written to do. Unless it's a program written specifically for managing pythons various parts. It's kind of like the problem of separating content, context, and presentation in web pages. Sometimes it's hard to do.
Yep - 99.99% of python code will never care if this is ever fixed. However, the fact that we've started using acceleration modules and pseudo-packages in the standard library means that "things should just work" is being broken subtly in the stuff we're shipping ourselves (either by creating pickling problems, as in unittest, or misleading introspection results, as in functools and datetime).
And if we're going to fix it at all, we may as well fix it right :)
Fixing it right mean taking a longer view point. What would we like all this stuff to look like two or more versions down the road? (Probably python 3.5 or 3.6)
Doing the minimum to fix just the immediate problems is a short term veiw. That will work, but if we can align it with up with a longer view solution, it would be better.
If we can't decide what the long term solution might be, then we may be better off using private attributes and methods for now for these isolated situations.
How about making __module__ a property on accelerated objects, that looks for a global flag, then returned either, _module__ or _alt_module__ depending on the flag? (or some other way of store those values)
Pickle could set the flag so it can get what it needs from __module__, then unset it when it's done.