On 2012-06-07, at 10:45 AM, R. David Murray wrote: > On Thu, 07 Jun 2012 07:00:29 -0700, Larry Hastings <la...@hastings.org> wrote: >> On 06/06/2012 11:56 PM, Nick Coghlan wrote: >>> I'd say return a copy in the first case to be safe against accidental >>> modification. If someone actually wants in-place modification, they >>> can access __signature__ directly. >> >> I really don't understand this anxiety about mutable Signature objects. >> Can you give a plausible example of "accidental modification" of a >> Signature object? I for one--as clumsy as I am--cannot recall ever >> "accidentally" modifying an object. > > Maybe it would make more sense if you read that as "naively" rather than > "accidentally"? > > In the 3.3 email extension I made a similar decision, although there I > went even further and made the objects read only. My logic for doing > this is that a naive user would...naively...try to set the attributes > and expect the object they got it from to change, but that object (a > string subclass) is inherently read-only. > > I am thinking that in fact we may ultimately want to return copies of > these objects that are mutable, because that might be useful, but I'm > starting with read-only because it is easy to make them mutable later > but pretty much impossible (backward compatibility wise) to make them > immutable if they start mutable. > > I see the signature object as a very parallel case to this, except that > it is already obvious that having them be a mutable copy is useful.
I think the copy approach is better for Signatures, the immutability. It should be OK to, for instance, get a signature, modify some parameters information, and then try to bind some arguments. Again, there's a care for decorators, where they get a signature, and modify it, as the wrapper's signature is different from the original function's. - Yury _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
