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