On Sun, 13 Feb 2005 12:01:42 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> True. It wouldn't cause a problem within my __init__, since the >> attribute is reassigned after the deepcopy, though should anyone else >> deepcopy an instance... Definitely better that the deepcopy throws the >> TypeError. But why shouldn't we be able to copy a non-method function? > >I honestly don't know, although I'm hard-pressed to see how doing so would >ever >be *useful*. Duplicating *parts* of a function would seem to make sense (to >build a new function which is similar, but not identical), but duplicating the >whole thing seems rather pointless. Although I guess you could just pickle it >and then unpickle the result to make a copy :) > It's not so much that copying a function is useful as it would be nice if copy and deepcopy didn't fail on plain functions, as there are cases where objects would need to store references to such functions. Imagine classes implementing operations on functions such as numeric differentiation and integration (while symbolic differentiation & integration would probably be better for production code, the example still stands). As it is, a little extra work would be needed to support deepcopying such classes. And it's always nice to avoid work. Thanks for your help and feedback on this. -- http://mail.python.org/mailman/listinfo/python-list