@Property utility in this case

Question

Given the following class:

class BasicRNNCell(RNNCell): """The most basic RNN cell.""" def __init__(self, num_units, input_size=None): self._num_units = num_units self._input_size = num_units if input_size is None else input_size @property def input_size(self): return self._input_size @property def output_size(self): return self._num_units @property def state_size(self): return self._num_units def __call__(self, inputs, state, scope=None): """Most basic RNN: output = new_state = tanh(W * input + U * state + B).""" with vs.variable_scope(scope or type(self).__name__): # "BasicRNNCell" output = tanh(linear([inputs, state], self._num_units, True)) return output, output 

I do not understand why they use the property function in this case. Using the property decorator for the input_size function allows you to call input_size on the object, let it call the cell of this class, but why not just call cell._input_size? Can someone tell me why this is helpful?

Answer 1

Using Python properties has advantages over the direct access you offer.

Consider the implementation

 class Foo(object): def __init__(self): self.bar = ... 

against.

 class Foo(object): def __init__(self): self._bar = ... ... @property def bar(self): return self._bar 

Suppose you have foo = Foo() . In the first case, you access the element as foo.bar . That means you can do

 print foo.bar foo.bar = 3 

Ie, you cannot restrict the modification of bar . In the latter case, however, relying on an agreement not to have access to things prefixed with _ , admittedly, you can do

 print foo.bar 

but

 foo.bar = 3 

will raise an exception.

In addition, using property definitions , you can control the change of bar , as well as perform checks and other interesting things:

 class Foo(object): def __init__(self): self._bar = ... ... @property def bar(self): return self._bar @bar.setter def bar(self, value): if something_of_value(value): raise Whatever self._bar = value 

Answer 2

(low profile: ON)

I think this is an abuse of properties. Back on the same day, C ++ and Java programmers realized that exposure to public class members could make their code fragile. You cannot change your mind about how the data for this variable is generated without changing the class interface and without breaking compatibility. So people started using getters and setters (functions that access private members) for added flexibility, and was also clicked to hide all participants ... just in case.

When other languages ​​formalized properties, they sometimes had the same problem with class interfaces. You cannot move from a variable to a property without changing the interface and breaking backward compatibility again. Thus, it was clicked to do all the properties of the variables ... just in case.

Python is not like that. Now you can have a member foo , change it to a property tomorrow, and the class interface will not change. In my opinion, this is just a protective practice of coding from another language and is not needed here.

(humble opinion mode: OFF)