[Python-Dev] Updated PEP 362 (Function Signature Object)

[Yury Selivanov]

On 2012-06-07, at 10:45 AM, R. David Murray wrote:
> On Thu, 07 Jun 2012 07:00:29 -0700, Larry Hastings <larry at 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