On 10/12/2020 13:06, Paul Bryan wrote:
Thanks for the comprehensive response, dn!
I guess I'm influenced by data classes here, where the object's
attribute type hints are represented by class variable annotations.
I'm a great fan of them too - the saving of 'boilerplate code' does it
for me
Thanks for the comprehensive response, dn!
I guess I'm influenced by data classes here, where the object's
attribute type hints are represented by class variable annotations.
On Thu, 2020-12-10 at 07:49 +1300, dn via Python-list wrote:
> On 09/12/2020 13:17, Paul Bryan wrote:
> > Would this be a
On 09/12/2020 13:17, Paul Bryan wrote:
Would this be a reasonably correct way to annotate a property with a
type hint?
class Foo:
... bar: int
If we build a class with (only) the above two lines, Python's help
lookup offers the following documentation:
<<<
Help on Foo in module __mai
Le 26/06/2020 à 15:12, Peter Otten a écrit :
Unknown wrote:
The getter/setter of the property builtin return a new property
p = property()
q = p.getter(None)
p is q
False
where you
def getter(self, fget):
self.fget = fget
return self
modify the existing one.
Le 26/06/2020 à 10:16, R.Wieser a écrit :
ast,
I have absolutily /no idea/ about how that "fahrenheit = property()" comes
into play though.
It just creates an empty property object.
You can then fill this object with the read/write/delete functions
with the methods getter, setter, del
ast wrote at 2020-6-26 09:02 +0200:
>Hello,
>
>I am wondering why this code is OK:
>
>class Temperature:
> def __init__(self):
> self.celsius = 0
>
> fahrenheit = property()
>
> @fahrenheit.getter
> def fahrenheit(self):
> return 9/5*self.celsius +32
>
> @fahrenheit.
Unknown wrote:
> Hello,
>
> I am wondering why this code is OK:
>
> class Temperature:
> def __init__(self):
> self.celsius = 0
>
> fahrenheit = property()
>
> @fahrenheit.getter
> def fahrenheit(self):
> return 9/5*self.celsius +32
>
> @fahrenheit.setter
> def f
> On 26 Jun 2020, at 08:02, ast wrote:
>
> Hello,
>
> I am wondering why this code is OK:
>
> class Temperature:
>def __init__(self):
> self.celsius = 0
>
>fahrenheit = property()
>
>@fahrenheit.getter
>def fahrenheit(self):
> return 9/5*self.celsius +32
>
Ivan Ivanyuk wrote:
> On Thu, 18 Jun 2020 at 11:26, Peter Otten <__pete...@web.de> wrote:
>>
>> Ivan Ivanyuk wrote:
>>
>> > Hello All,
>> >
>> > I have some trouble using @dataclass together with @property decorator
>> > or property() function.
>> >
>> > From the documentation and PEP is seems tha
On Thu, 18 Jun 2020 at 11:26, Peter Otten <__pete...@web.de> wrote:
>
> Ivan Ivanyuk wrote:
>
> > Hello All,
> >
> > I have some trouble using @dataclass together with @property decorator
> > or property() function.
> >
> > From the documentation and PEP is seems that the intended behaviour of
> >
Ivan Ivanyuk wrote:
> Hello All,
>
> I have some trouble using @dataclass together with @property decorator
> or property() function.
>
> From the documentation and PEP is seems that the intended behaviour of
> @dataclass is to be the same as normal __init__() that sets instance
> variables.
>
Thanks to Rob, Cameron, Ian, Chris and Kirill for the detailed explanations.
Very helpful,
Irv
> On Dec 20, 2017, at 3:56 PM, Irv Kalb wrote:
>
> I am trying to work through the concept of the @property decorator with
> respect to object oriented programming.
>
> I believe that I understand
On 20/12/17 21:39, Stefan Ram wrote:
Irv Kalb writes:
about property decorators.
The code
@property
def salary(self): pass
@salary.setter
def salary(self, newSalary): pass
is an abbreviation for
def salary_get(self): pass
salary = property( salary_get )
def salary_set(self, newSalary
On 20Dec2017 15:56, Irv Kalb wrote:
I am trying to work through the concept of the @property decorator with
respect to object oriented programming.
I believe that I understand how the @property and @.setter work -
and that they are used to turn what looks like direct access to instance varia
On Thu, Dec 21, 2017 at 2:38 PM, Ian Kelly wrote:
> On Wed, Dec 20, 2017 at 5:56 PM, Irv Kalb wrote:
>> 2) Alternatively, if the getter was going to use the @property decorator,
>> then it would seem complimentary to have the decorator name for the
>> associated setter function to have the wo
On Wed, Dec 20, 2017 at 5:56 PM, Irv Kalb wrote:
> My questions about this are really historical. From my reading, it looks
> like using an @property decorator is a reference to an older approach using a
> built in "property" function. But here goes:
>
> 1) Why were these decorator names chose
On 12/20/2017 03:56 PM, Irv Kalb wrote:
I am trying to work through the concept of the @property decorator with
respect to object oriented programming.
I believe that I understand how the @property and @.setter work -
and that they are used to turn what looks like direct access to instance va
On 21/02/2014 18:58, K Richard Pixley wrote:
Could someone please explain to me why the two values at the bottom of
this example are different?
Python-3.3 if it makes any difference.
Is this a difference in evaluation between a class attribute and an
instance attribute?
Yes, see below.
--r
On 12/21/2013 11:59 AM, Dennis Lee Bieber wrote:
On 21 Dec 2013 11:31:22 GMT, Steven D'Aprano
I don't know. What is it? I'm sure your code is the most fabulous,
awesome and brilliant thing since Grace Hopper came up with FORmula
TRANslation back in the 1950s,
As I recall, Grace Hopper was i
On 21/12/2013 11:31, Steven D'Aprano wrote:
On Fri, 20 Dec 2013 15:26:10 -0600, Brian Bruggeman wrote:
Is this something that would be pep-able?
I don't know. What is it? I'm sure your code is the most fabulous,
awesome and brilliant thing since Grace Hopper came up with FORmula
TRANslation b
On Sat, Dec 21, 2013 at 2:14 AM, Peter Otten <__pete...@web.de> wrote:
> If I were to implement something like this I'd probably use the old trick
> with nested functions:
>
> def getset(f):
> funcs = f()
> return property(funcs.get("get"), funcs.get("set"))
>
> class A(object):
> @gets
On Fri, 20 Dec 2013 15:26:10 -0600, Brian Bruggeman wrote:
> Is this something that would be pep-able?
I don't know. What is it? I'm sure your code is the most fabulous,
awesome and brilliant thing since Grace Hopper came up with FORmula
TRANslation back in the 1950s, but my browser has over ei
Brian Bruggeman wrote:
> Is this something that would be pep-able?
>
> https://gist.github.com/brianbruggeman/8061774
There's no need to put such a small piece of code into an external
repository.
> class someAwesomeClass(object):
> """ an example """
>
> @property
> def some_
Ian Kelly wrote:
On Wed, Dec 14, 2011 at 1:28 AM, Felipe O wrote:
Hi All,
I was wondering what everyone's thought process was regarding properties.
Lately I find I've been binging on them and have classes with > 10
properties. While pylint doesn't complain (yet), it tends to be picky about
k
On Wed, Dec 14, 2011 at 1:28 AM, Felipe O wrote:
> Hi All,
> I was wondering what everyone's thought process was regarding properties.
> Lately I find I've been binging on them and have classes with > 10
> properties. While pylint doesn't complain (yet), it tends to be picky about
> keeping instan
Hey yes it's working that way. But I don't like it very much either. If as OKB
said the whole point is that outside functions can't detect a property then I'm
going to stick with the non-decorator way. Thanks anyway.
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Nov 10, 2011 at 9:17 PM, Laurent wrote:
> Yes using a separate class variable would transfer the problem to the class
> level. But adding 10 class variables if I have 10 properties would be ugly.
> Maybe I should reformulate the subject of this thread to "is there some
> python magic to
Laurent wrote:
> Yes using a separate class variable would transfer the problem to
> the class level. But adding 10 class variables if I have 10
> properties would be ugly. Maybe I should reformulate the subject of
> this thread to "is there some python magic to pass parameters to
> decorator-decl
Yes using a separate class variable would transfer the problem to the class
level. But adding 10 class variables if I have 10 properties would be ugly.
Maybe I should reformulate the subject of this thread to "is there some python
magic to pass parameters to decorator-declared properties ?"
--
On Nov 11, 2:03 pm, Laurent wrote:
> Hi. I couldn't find a way to overwrite a property declared using a decorator
> in a parent class.
> class Polite:
> @property
> def greeting2(self, suffix=", my dear."):
> return self._greeting + suffix
Here you set up greeting2 as a property
So subclass B has no access to __not_here in A after all...
OK, in one of legacy Python I supported there are a lot of code floating
around like this. It works OK (in term of business logic and unit test).
That's probably due to luck :-)
It also uses a lot of __slot__ = ['attr_a', 'attr_b'...] in
On Mon, Jul 11, 2011 at 11:21 AM, Anthony Kong
wrote:
> Awesome, Thomas. The trick only works if there is only one leading
> underscore in the method names.
> The following example works as I expected for the derived class B.
> class A(object):
> def __init__(self):
> self.__not_here =
On Mon, Jul 11, 2011 at 10:53 AM, Anthony Kong
wrote:
> Thanks again for your input, Thomas.
> I normally prefer
> not_here = property(lambda self: self.__get_not_here(), lambda self, v:
> self.__set_not_here(v))
> than
> not_here = property(__get_not_here, __set_not_here)
> Because it allows me t
On 2:59 PM, Anthony Kong wrote:
> So the question: is it possible to use lambda expression at all for
> the setter? (As in the last, commented-out line)
>
> Python interpreter will throw an exception right there if I use the
> last line ('SyntaxError: lambda cannot contain assignment'). I'd use
>
>
> PS: are you sure the lambda self: self.__foo() trick works, with
> subclasses or otherwise? I haven't tested it, and I'm not saying it
> doesn't, but I have a feeling double-underscore name mangling might be a
> problem somewhere down the line?
>
>
Awesome, Thomas. The trick only works if there
# On 07/11/2011 06:53 PM, Anthony Kong wrote:
# But decorator! Of course! Thanks for reminding me this.
#
# In your example, where does '@not_here' come from? (Sorry, this syntax
# is new to me)
class A(object):
def __init__(self):
self.not_here = 1
@property
def not_here(se
Good point! Need to get my terminology right. Thanks
On Tue, Jul 12, 2011 at 2:43 AM, Ian Kelly wrote:
> On Mon, Jul 11, 2011 at 9:54 AM, Anthony Kong
> wrote:
> > Hi, all,
> > This question is in the same context of my two earlier questions. This
> > question was raised by some python beginner
Thanks again for your input, Thomas.
I normally prefer
not_here = property(lambda self: self.__get_not_here(), lambda self, v:
self.__set_not_here(v))
than
not_here = property(__get_not_here, __set_not_here)
Because it allows me to have a pair getter/setter (when there is a need for
it). Use o
On Mon, Jul 11, 2011 at 9:54 AM, Anthony Kong wrote:
> Hi, all,
> This question is in the same context of my two earlier questions. This
> question was raised by some python beginners, and I would like to check with
> the list to ensure I provide a correct answer.
> Here is a code snippet I used t
On 07/11/2011 05:54 PM, Anthony Kong wrote:
> Hi, all,
>
> This question is in the same context of my two earlier questions. This
> question was raised by some python beginners, and I would like to check
> with the list to ensure I provide a correct answer.
>
> Here is a code snippet I used to de
On Sat, 01 Jan 2011 17:55:10 -0800, K. Richard Pixley wrote:
> Can anyone explain to me why this doesn't work?
>
> class Foo(object):
> @property
> @classmethod
> def f(cls):
> return 4
What does "doesn't work" mean? It works for me:
>>> class Foo(object):
... @pro
On 1/1/2011 6:55 PM, K. Richard Pixley wrote:
Can anyone explain to me why this doesn't work?
class Foo(object):
@property
@classmethod
def f(cls):
return 4
I mean, I think it seems to be syntactically clear what I'm trying to
accomplish. What am I missing?
First, because classmethod returns
Bruno Desthuilliers a écrit :
(snip)
You could write your own custom descriptor. Or just use an additional
level of indirection, ie:
myProperty = property(lambda self: self.myClassMethod())
Sorry, looks like I didn't read carefully enough. The above code won't
work if you intend to looku
Lie Ryan a écrit :
Bruno Desthuilliers wrote:
Lie Ryan a écrit :
Emanuele D'Arrigo wrote:
(snip)
Ultimately all I want is a non-callable class-level attribute
MyClass.myProperty that gives the result of MyClass.myClassMethod().
This works like what you seem to want (it's ugly):
Ugly, indeed
Bruno Desthuilliers wrote:
> Lie Ryan a écrit :
>> Emanuele D'Arrigo wrote:
> (snip)
>>> Ultimately all I want is a non-callable class-level attribute
>>> MyClass.myProperty that gives the result of MyClass.myClassMethod().
>>
>> This works like what you seem to want (it's ugly):
>
> Ugly, indeed.
Emanuele D'Arrigo wrote:
class MyClass(object):
@classmethod
def myClassMethod(self):
print "ham"
myProperty = property(myClassMethod, None, None)
... doesn't work and returns a TypeError: So, how do I do this?
Ultimately all I want is a non-callable class-level attrib
Lie Ryan a écrit :
Emanuele D'Arrigo wrote:
(snip)
Ultimately all I want is a non-callable class-level attribute
MyClass.myProperty that gives the result of MyClass.myClassMethod().
This works like what you seem to want (it's ugly):
Ugly, indeed. And an extreme case of arbitrary overcomplex
Emanuele D'Arrigo wrote:
> Greetings,
>
> today I did something like this:
>
> class MyClass(object):
>
> @classmethod
> def myClassMethod(self):
> print "ham"
>
> myProperty = property(myClassMethod, None, None)
>
> As many of you know this doesn't work and returns a Typ
Emanuele D'Arrigo a écrit :
Greetings,
today I did something like this:
class MyClass(object):
@classmethod
def myClassMethod(self):
Usually, the first argument of classmethods is named 'cls'
print "ham"
myProperty = property(myClassMethod, None, None)
As many of
Rafe wrote:
> Thanks for the idea Peter. What confuses me is why this only happens
> to @Property (and I assume other decorator related bindings?). Does it
> have something to do with the way the class gets built? 'Normal'
> attributes will raise AttributeErrors as expected, without triggering
> _
On Oct 27, 2:47 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> Rafewrote:
> > Can anyone explain why this is happening?
>
> When an attribute error is raised that is an indication that the requested
> attribute doesn't exist, and __getattr__() must be called as a fallback.
>
> > I can hack a work-aro
OT... Sorry about he spam.
Thanks for taking the time to post this Duncan.
I had the same thought. I have posted to this list before but never
experienced anything like this wait. I figured it was possible that I
hit "Reply to Author" the first time so I sent it again. I waited
about 8 hours befor
Rafe wrote:
> Can anyone explain why this is happening?
When an attribute error is raised that is an indication that the requested
attribute doesn't exist, and __getattr__() must be called as a fallback.
> I can hack a work-around,
> but even then I could use some tips on how to raise the 'rea
Rafe <[EMAIL PROTECTED]> wrote:
> Peter Oten pointed me in the right direction. I tried to reply to his
> post 2 times and in spite of GoogleGroups reporting the post was
> successful, it never showed up.
This is the third variant on your message that has shown up in the
newsgroup.
Please be aw
On Oct 24, 1:47 am, Rafe <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've encountered a problem which is making debugging less obvious than
> it should be. The @property decorator doesn't always raise exceptions.
> It seems like it is bound to the class but ignored when called. I can
> see the attribute u
Rafe wrote:
The docs seem to suggest this is impossible:
"Called when an attribute lookup has not found the attribute in the
usual places (i.e. it is not an instance attribute nor is it found in
the class tree for self).
Getting an AttributeError is the way that the interpreter
machinery tells
On Oct 24, 9:58 am, Peter Otten <[EMAIL PROTECTED]> wrote:
> Rafe wrote:
> > On Oct 24, 2:21 am, Christian Heimes <[EMAIL PROTECTED]> wrote:
> >> Rafewrote:
> >> > Hi,
>
> >> > I've encountered a problem which is making debugging less obvious than
> >> > it should be. The @property decorator doesn'
On Oct 24, 9:58 am, Peter Otten <[EMAIL PROTECTED]> wrote:
> Rafe wrote:
> > On Oct 24, 2:21 am, Christian Heimes <[EMAIL PROTECTED]> wrote:
> >> Rafewrote:
> >> > Hi,
>
> >> > I've encountered a problem which is making debugging less obvious than
> >> > it should be. The @property decorator doesn'
On Fri, 24 Oct 2008 01:47:10 -0700, Rafe wrote:
> Hi,
>
> I've encountered a problem which is making debugging less obvious than
> it should be. The @property decorator doesn't always raise exceptions.
I don't think that's the problem. I think properties do correctly raise
all exceptions that o
On Fri, 24 Oct 2008 09:34:36 -0700, Rafe wrote:
>> You must subclass from "object" to get a new style class. properties
>> don't work correctly on old style classes.
>>
>> Christian
>
> All classes are a sub-class of object. Any other ideas?
Only in Python 3. If you are relying on that to be tru
Rafe wrote:
> On Oct 24, 2:21 am, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> Rafewrote:
>> > Hi,
>>
>> > I've encountered a problem which is making debugging less obvious than
>> > it should be. The @property decorator doesn't always raise exceptions.
>> > It seems like it is bound to the clas
On Oct 24, 2:21 am, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Rafewrote:
> > Hi,
>
> > I've encountered a problem which is making debugging less obvious than
> > it should be. The @property decorator doesn't always raise exceptions.
> > It seems like it is bound to the class but ignored when ca
Rafe wrote:
Hi,
I've encountered a problem which is making debugging less obvious than
it should be. The @property decorator doesn't always raise exceptions.
It seems like it is bound to the class but ignored when called. I can
see the attribute using dir(self.__class__) on an instance, but when
> P.S. How did my post manage to ignite a mini flame war?!
Because of the high resident troll quota in replies - which is created by
just one rather annoying member of this community...
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Venerable Pythonistas,
Looks like a pretty unanimous vote in favour of custom descriptor
usage rather than the more generic property() BIF for my purposes.
This is going to tidy and firm up my library code very nicely ;-)
Thanks very much for your responses. Your assistance is greatly
appreciate
David Moss a écrit :
Hi,
I want to manage and control access to several important attributes in
a class and override the behaviour of some of them in various
subclasses.
Below is a stripped version of how I've implemented this in my current
bit of work.
It works well enough, but I can't help f
On Aug 24, 10:41 pm, alex23 <[EMAIL PROTECTED]> wrote:
> On Aug 25, 12:42 pm, castironpi <[EMAIL PROTECTED]> wrote:
>
> > I'm baffled. I don't understand what you write.
>
> Which is pretty much how I feel about -all- of your posts.
Alright. You're articulate. I'm getting a better picture of
On Aug 25, 3:03 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> May I ask both of you to continue this in private?
Certainly. But be warned, I -will- continue posting publicly if I
believe someone is misinforming others here, whether it's willful or
not.
--
http://mail.python.org/mailman/list
En Mon, 25 Aug 2008 00:41:42 -0300, alex23 <[EMAIL PROTECTED]> escribió:
> On Aug 25, 12:42 pm, castironpi <[EMAIL PROTECTED]> wrote:
>> I'm baffled. I don't understand what you write.
> Which is pretty much how I feel about -all- of your posts.
May I ask both of you to continue this in privat
On Aug 25, 12:42 pm, castironpi <[EMAIL PROTECTED]> wrote:
> I'm baffled. I don't understand what you write.
Which is pretty much how I feel about -all- of your posts.
> I think someone in
> my shoes would be justified in dismissing it as either malicious or a
> miscommunication.
No, it's f
On Aug 24, 7:43 pm, alex23 <[EMAIL PROTECTED]> wrote:
> castironpi <[EMAIL PROTECTED]> wrote:
> > Python isn't as clever as you think. It's a language.
>
> Yet another non-sequitur response from you. At which point in my post
> did I make any such claims about Python's 'cleverness'?
>
> > Do you
castironpi <[EMAIL PROTECTED]> wrote:
> Python isn't as clever as you think. It's a language.
Yet another non-sequitur response from you. At which point in my post
did I make any such claims about Python's 'cleverness'?
> Do you want a
> link to clever code?
Not if you wrote it or find it c
On Aug 24, 5:00 am, alex23 <[EMAIL PROTECTED]> wrote:
> castironpi <[EMAIL PROTECTED]> wrote:
> > and we'll write Python.
>
> I haven't seen anything you've contributed to this group that would so
> far be considered well-written Python.
>
> Confusing and border-line insane, yes. Pythonic? Not at a
On Aug 22, 1:18 pm, David Moss <[EMAIL PROTECTED]> wrote:
> It works well enough, but I can't help feeling there a cleaner more
> readable way of doing this (with less duplication, etc).
>
> Is this as good as it gets or can this be refined and improved
> especially if I was to add in a couple more
castironpi <[EMAIL PROTECTED]> wrote:
> and we'll write Python.
I haven't seen anything you've contributed to this group that would so
far be considered well-written Python.
Confusing and border-line insane, yes. Pythonic? Not at all.
Here's a tip: try actually developing some real-world applica
On Aug 22, 11:18 am, David Moss <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I want to manage and control access to several important attributes in
> a class and override the behaviour of some of them in various
> subclasses.
>
> Below is a stripped version of how I've implemented this in my current
> bit
On Fri, Aug 22, 2008 at 1:49 PM, Miles <[EMAIL PROTECTED]> wrote:
> from operator import attrgetter
> class attrsetter(object):
>def __init__(self, attr):
>self._attr = attr
>def __call__(self, object, value):
>setattr(object, self._attr, value)
This solution is very nice,
David Moss wrote:
Hi,
I want to manage and control access to several important attributes in
a class and override the behaviour of some of them in various
subclasses.
Below is a stripped version of how I've implemented this in my current
bit of work.
It works well enough, but I can't help feel
On Aug 22, 12:18 pm, David Moss <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I want to manage and control access to several important attributes in
> a class and override the behaviour of some of them in various
> subclasses.
>
> Below is a stripped version of how I've implemented this in my current
> bit
On Fri, Aug 22, 2008 at 12:18 PM, David Moss <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I want to manage and control access to several important attributes in
> a class and override the behaviour of some of them in various
> subclasses.
>
> Below is a stripped version of how I've implemented this in my c
On Aug 22, 11:18 am, David Moss <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I want to manage and control access to several important attributes in
> a class and override the behaviour of some of them in various
> subclasses.
>
> Below is a stripped version of how I've implemented this in my current
> bit
On 17 juil, 16:57, mk <[EMAIL PROTECTED]> wrote:
> It seems like getter is defined in such way that it passes only 'self':
>
> class FunDict(dict):
> def __init__(self):
> self.fundict = dict()
What's the use of inheriting from dict here ???
> def fget(self, fun):
I don't understand what you're trying to do here.
On Thu, Jul 17, 2008 at 10:57 AM, mk <[EMAIL PROTECTED]> wrote:
>
> It seems like getter is defined in such way that it passes only 'self':
>
>
> class FunDict(dict):
>def __init__(self):
>self.fundict = dict()
>
>d
On May 9, 9:05 pm, George Sakkis <[EMAIL PROTECTED]> wrote:
> Using the overridable property recipe [1],
> [1]http://infinitesque.net/articles/2005/enhancing%20Python's%20property...
Thanks, this is a great solution!
Joseph
--
http://mail.python.org/mailman/listinfo/python-list
On May 9, 5:20 pm, Joseph Turian <[EMAIL PROTECTED]> wrote:
> If I have a property in a derived class, it is difficult to override
> the get and set functions: the property's function object had early
> binding, whereas the overriden method was bound late.
> This was previously discussed:
> http
On Fri, May 9, 2008 at 3:20 PM, Joseph Turian <[EMAIL PROTECTED]> wrote:
> Could someone demonstrate how to implement the proposed solutions that
> allow the property to be declared in the abstract base class, and
> refer to a get function which is only implemented in derived classes?
One way is t
Joseph Turian wrote:
If I have a property in a derived class, it is difficult to override
the get and set functions: the property's function object had early
binding, whereas the overriden method was bound late.
This was previously discussed:
http://groups.google.com/group/comp.lang.python/br
Alex Fainshtein schrieb:
> As you see, getter works properly. But when assigning to property, setter is
> not called, as I would expect. prop is simply replaced with whatever is
> assigned and ceased being a property.
properties work only for new style classes. You have to subclass your
class from
En Fri, 02 May 2008 18:29:57 -0300, Alex Fainshtein
<[EMAIL PROTECTED]> escribió:
Question: what I am doing wrong? Here, I am defining class with property
member:
class Test:
def getter(self):
print "Getter called."
return 'a'
def setter(self, val):
print "Se
En Mon, 25 Feb 2008 18:50:20 -0200, <[EMAIL PROTECTED]> escribió:
> Hi,
> I would like to pass additional constants to the property data-
> descriptor, so it is not necessary to write many methods which differ
> just by constant defined in the method body.
> Till now I can do this:
>
> class MyCla
On Jan 11, 6:20 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Lie wrote:
> > Is there a way to create a property with arguments?
>
> That's called method in Python, and has it's own syntax. You cannot
> assign to methods.
So you've got to use methods? It was in VB.NET that I learned about
proper
Lie wrote:
> Is there a way to create a property with arguments?
That's called method in Python, and has it's own syntax. You cannot
assign to methods.
> Or an index value like a list?
Make the property that returns a list-like object (hooking __getitem__,
__setitem__, etc).
--
http://m
Manu Hack a écrit :
> hi all,
>
> If I have a class A with A.x, A.y, A.z. A.y and A.z are property and
> in order to compute the value of them, A.y depends on A.x while A.z
> depends on A.y and A.x. If I call A.y, and A.z, the value A.y would
> be computed twice. Is there a smart way to avoid t
On Oct 9, 1:20 am, "Manu Hack" <[EMAIL PROTECTED]> wrote:
> hi all,
>
> If I have a class A with A.x, A.y, A.z. A.y and A.z are property and
> in order to compute the value of them, A.y depends on A.x while A.z
> depends on A.y and A.x. If I call A.y, and A.z, the value A.y would
> be computed tw
gamehack wrote:
> Hi all,
>
> I was looking around the net to figure out how I can use the
> property() descriptor to make a property readable by everyone and only
> settable by the class or any derived classes. Thanks.
>
> Regards,
> gh
>
Congratulations, you have discovered a principal use of
gamehack wrote:
> Hi all,
>
> I was looking around the net to figure out how I can use the
> property() descriptor to make a property readable by everyone and only
> settable by the class or any derived classes. Thanks.
Forget it. You can try and come up with an implementation that will check
th
En Thu, 08 Mar 2007 08:04:38 -0300, <[EMAIL PROTECTED]> escribió:
> Gabriel Genellina:
>> You miss this common way, that does not depend on metaclasses,
>> nor base classes, nor custom decorators...
>
> My purpose was to discuss a new syntax. The other stuff is mostly for
> reference, to show that
Gabriel Genellina:
> You miss this common way, that does not depend on metaclasses,
> nor base classes, nor custom decorators...
My purpose was to discuss a new syntax. The other stuff is mostly for
reference, to show that lot of (some) people has tried to find
alternative solutions to a problem t
En Thu, 08 Mar 2007 06:34:12 -0300, <[EMAIL PROTECTED]> escribió:
> Probably you have already discussed this topic, but maybe you can
> stand touching it again briefly.
> Maybe properties aren't used so often to deserve a specific syntax,
> but I don't like their syntax much. Here I show some alte
king kikapu wrote:
> Your example Dennis, work as expected. I understand the mistake i have
> made. But when i try to fix the original code usihn @property now, it
> gives me the same error.
> So, here it is:
>
> class Person(object):
> _age = 0
>
> @property
> def age():
> def
1 - 100 of 134 matches
Mail list logo
