> Yes, the get part works. The set part is a pain, and a bit ugly:
>
> super(B, B).foo.__set__(self, value)
>
> There is an issue for this on the tracker:
> http://bugs.python.org/issue14965
>
Thank you Ethan!
The superprop pure Python implementation is very promising. (
http://bugs.python.or
On 09/11/2016 08:28 AM, Peter Otten wrote:
Nagy László Zsolt wrote:
Yes, I believe it does. (Others may disagree. This is a design
question and very much a matter of style, not hard fact.) I would have
an explicit action "set_content" which will set the value of an input
field, the inner text
Nagy László Zsolt wrote:
>
>> Yes, I believe it does. (Others may disagree. This is a design
>> question and very much a matter of style, not hard fact.) I would have
>> an explicit action "set_content" which will set the value of an input
>> field, the inner text of a textarea, the checked state
Yes, I believe it does. (Others may disagree. This is a design
question and very much a matter of style, not hard fact.) I would have
an explicit action "set_content" which will set the value of an input
field, the inner text of a textarea, the checked state of a check box,
etc.
In other words,
On Sun, Sep 11, 2016 at 9:31 PM, Nagy László Zsolt wrote:
> The "value of a form field" must have a unified interface. So when I do
> " textfield.value = some_value " then I expect that the changed value
> will be represented on the UI *if it has an UI representation*. The
> widget needs to be abl
On Sun, Sep 11, 2016 at 9:17 PM, Nagy László Zsolt wrote:
>> Subclassing and overriding are part of the interface of a class,
>> albeit an interface that only a subset of other classes will use.
>> Think carefully about why, if this is meant to be made available, it
>> isn't simply a method call.
> Even the problem seems to rather defeat the purpose of a property. A
> property should be very simple - why do you need to override it and
> call super()? Doesn't this rather imply that you've gone beyond the
> normal use of properties *already*?
Here are some of my classes that can represent da
> Even the problem seems to rather defeat the purpose of a property. A
> property should be very simple - why do you need to override it and
> call super()? Doesn't this rather imply that you've gone beyond the
> normal use of properties *already*?
I'm not sure about that. I'm going to send a USE
On Sun, Sep 11, 2016 at 8:02 PM, Nagy László Zsolt wrote:
> But this solution almost defeats the purpose of properties. E.g. a
> property should look like an attribute, and its behaviour should be
> manipulated through its name (and not another special method that must
> be exposed to subclasses.)
By the way, I know that I can use a "property virtualizer", something
like this:
import inspect
class A:
def __init__(self, prop=0):
self.__prop = prop
def _prop_get(self):
return self.__prop
def _prop_set(self, value):
self.prop_set(value)
Example code:
class A:
def __init__(self, prop=0):
self.__prop = prop
@property
def prop(self):
return self.__prop
@prop.setter
def prop(self, value):
self.__prop = value
class B(A):
@A.prop.setter
def prop(self, value):
print
11 matches
Mail list logo
