[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