[Python-Dev] PEP 362: 4th edition
Ethan Furman
ethan at stoneleaf.us
Tue Jun 19 03:17:57 CEST 2012
Yury Selivanov wrote:
> On 2012年06月18日, at 4:25 PM, Guido van Rossum wrote:
>>> On Mon, Jun 18, 2012 at 11:09 AM, Yury Selivanov
>> <yselivanov.ml at gmail.com> wrote:
>>> The rationale is that sometimes you need to modify signatures.
>>> For instance, in decorators.
>> A decorator should make a modified copy, not modify it in place (since
>> the signature of the decorated function does not change, and you have
>> no guarantee that that function is no longer accessible.)
>>>> It seems that we have the following options for 'signature(obj)':
>> 1. If 'obj' has a '__signature__' attribute - return a copy of it,
> if not - create a new one.
>> 2. If 'obj' has a '__signature__' attribute - return it,
> if not - create a new one.
>> 3. Same as '2', but Signature is also immutable.
>>> The first option is the one currently implemented. Its advantage
> is consistency - we always have a Signature we can safely modify.
>> The second option has a design flaw - sometimes the result Signature
> is safe to modify, sometimes not, you never know.
>> The third option is hard to work with.
> Instead of:
>> sig = signature(wrapper)
> sig.parameters.popitem(last=False)
> decorator.__signature__ = sig
>> We will have (because Signature is immutable):
>> sig = signature(wrapper)
> params = OrderedDict(sig.parameters.items())
> params.popitem(last=False)
>> attrs = {'parameters': params}
> try:
> ra = sig.return_annotation
> except AttributeError:
> pass
> else:
> attrs['return_annotation'] = ra
>> decorator.__signature__ = Signature.from_attrs(**attrs)
>> It looks like a total overkill (unless we can come up with a nicer
> API).
>> So it was decided to go with the first option, as it has the least
> complications. Plus, the copying itself should be fast, as
> Signatures contain little information.
>> What do you think?
Option 1 makes sense to me -- we already know we'll have cases where we
want to modify a given signature, so why make it hard on ourselves?
~Ethan~
More information about the Python-Dev
mailing list