newb question about @property

[bartc]

On 04/10/2017 14:41, Ian Kelly wrote:
> On Wed, Oct 4, 2017 at 5:07 AM, bartc <bc at freeuk.com> wrote:

>> For that matter, I don't think Python has such a feature either. So that you
>> write for example:
>>
>>    const C = 123345
>>
>> and then whenever C appears within the code, it's implemented as:
>>
>>    LOAD_CONST (123345)

> Python has the simplest named constants of all:
> 
> C = 12345
> 
> As long as you don't subsequently change it, it's a constant. And it's
> very simple because it works just like any other variable.

Yes, but you don't want it to work like other variables!

In other languages, a known compile-time constant is essential in 
certain contexts, but even in Python there are advantages to such a 
feature, for example in more opportunities for optimisation.

Even if it's just so it can use LOAD_CONST instead of LOAD_GLOBAL (as 
such constants often are global).

The problems with doing this in current CPython are first, that all such 
identifiers are dynamic: you can assign anything to them at any time. 
Also that some may be inside imported files, which the byte-code 
compiler will not know about until its too late.

(There are ways around those but it would be an impossible sell when 
most people are not convinced that lightweight named constants are useful.)

>> I'm trying to think of a real example where I've had to add a cache to to a
>> function, whatever that even means (memoisation?).
> 
> You've never used a dynamic programming algorithm?

I had to look up what it means, but I still didn't see any practical 
examples.

Probably I've done such coding, but I didn't give it a fancy name, and 
more likely just considered it data caching.


 > Descriptors are a bit unique to Python, I'll grant, but mostly they're
 > just used in the form of properties. Here's a list of languages that
 > support properties:
 > https://en.wikipedia.org/wiki/Property_(programming)#Example_syntax

"A property, in some object-oriented programming languages, is a special 
sort of class member, intermediate in functionality between a field (or 
data member) and a method."

But Python has some problems just in using fields. If you wanted say a 
data type with two fields called x and y, then AFAIK you just create any 
suitable class, but you don't need to specifically declare those two fields:

  class any():
      pass

  p=any()
  p.x=10
  p.y=20

But you also do this:

  p.z=30

and it magically acquires a third field! Or you want to modify p.x, but 
accidentally type:

  p.c=40

No error. Some would perceive all this as an advantage, but it means you 
can't just declare a lightweight struct or record 'Point' with exactly 
two fields x and y. You have to use other solutions ('namedtuples' or 
whatever, which probably are immutable so that don't work the same way).

This is another example of neglecting the basics, but going for more 
advanced, perhaps more sexy features instead.

Result? You can't just look at my 'any' class and see what fields it 
uses. You can't even just look at the static source code. You have to 
run the program to find out. And it might be different each time.

-- 
bartc