Sorry folks, I haven't been keeping up with this specific thread, so I'm
going to just jump in with an opinion no matter how ignorant... :-)
On Sun, Jan 25, 2015 at 07:20:18AM +1100, Cameron Simpson wrote:
> Like Alan, you've missed my intent here.
>
> To quote from my reply to Alan:
>
> I am
On 24Jan2015 15:03, Mark Lawrence wrote:
On 24/01/2015 01:50, Cameron Simpson wrote:
My intuition is that a function is costly (potentially) and that
consulting an attribute is very cheap. I don't want to break such
intuition.
It's not just your intuition, it's a fact. Function calls are co
On 24/01/2015 01:50, Cameron Simpson wrote:
My intuition is that a function is costly (potentially) and that
consulting an attribute is very cheap. I don't want to break such
intuition.
It's not just your intuition, it's a fact. Function calls are costly,
relative to attribute lookup that
On 24Jan2015 09:16, Alan Gauld wrote:
On 24/01/15 01:50, Cameron Simpson wrote:
On 24Jan2015 00:47, Alan Gauld wrote:
But why a property rather than a simple method?
Because it is a value that feels like an attribute.
OK, Having seen Dannys reply as well as yours I guess I see the logi
On 24/01/15 01:50, Cameron Simpson wrote:
On 24Jan2015 00:47, Alan Gauld wrote:
But why a property rather than a simple method?
Because it is a value that feels like an attribute.
OK, Having seen Dannys reply as well as yours I guess I see the logic.
I think Python's openness has lead to
On 24Jan2015 00:47, Alan Gauld wrote:
On 24/01/15 00:37, Cameron Simpson wrote:
By contrast, I use it a far bit (though still far less than non-property
methods). Generally for derived properties which are:
- cheap to compute i.e. O(1)
- which I want to abstract
- usually represent some pro
>
> But why a property rather than a simple method?
> Why is
>
> k = url.key
>
> better than
>
> k = url.key()
>
> for meeting those criteria?
My understanding is this is very much a Python-specific problem.
Python style encourages raw access to the attributes of an object via
direct lookup and a
On 24/01/15 00:37, Cameron Simpson wrote:
By contrast, I use it a far bit (though still far less than non-property
methods). Generally for derived properties which are:
- cheap to compute i.e. O(1)
- which I want to abstract
- usually represent some property which is stable, such as a
On 23Jan2015 20:37, Alan Gauld wrote:
On 23/01/15 11:47, jarod...@libero.it wrote:
Thanks so much for clear explanation!!! So in this way work .
In [38]: Test().x.__name__
Out[38]: 'x'
The decoratory proprerty dosen't help to create the class in fast way.. When
it is advisable use @property?
On 23/01/15 11:47, jarod...@libero.it wrote:
Thanks so much for clear explanation!!! So in this way work .
In [38]: Test().x.__name__
Out[38]: 'x'
The decoratory proprerty dosen't help to create the class in fast way.. When
it is advisable use @property?
Very rarely, and mainly when you need to
Thanks so much for clear explanation!!! So in this way work .
In [38]: Test().x.__name__
Out[38]: 'x'
The decoratory proprerty dosen't help to create the class in fast way.. When
it is advisable use @property?
___
Tutor maillist - Tutor@python.org
T
11 matches
Mail list logo
