Case Statements

Chris Angelico rosuav at gmail.com
Thu Mar 17 02:30:42 EDT 2016


On Thu, Mar 17, 2016 at 4:45 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Steven D'Aprano wrote:
>>
>> On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote:
>>
>>>    orig = globals()[cls.__name__]
>>
>>
>> I wouldn't want to rely on it working with decorator syntax either. Even
>> if
>> it does now, I'm not sure that's a language guarantee.
>
>
> The following idiom relies on similar behaviour:
>
>     @property
>     def x(self):
>         return self._x
>
>     @x.setter
>     def x(self, value):
>         self._x = value
>
> That's taken from the official docs, so I don't think
> this is likely to change any time soon.

Ooh, didn't think of that. So maybe it's a language guarantee that
hasn't been written down somewhere, and the "func = deco(func)"
version is a known-imperfect-equivalent, same as "for x in iter: yield
x" is an imperfect equivalent for "yield from iter".

It would be possible to support @x.setter by simply guaranteeing that
the decorator expression is evaluated prior to the function creation:

_tmp = x.setter # but without using an actual name
def x(self, value):
    self._x = value
x = _tmp(x)

But I doubt the language needs to go to this level of finickiness. In
fact, all it really needs is an acknowledgement that there are corner
cases:

http://bugs.python.org/issue26576

ChrisA



More information about the Python-list mailing list