Develop Reference

Python get and set methods versus #property decorator

I am exploring decorators in Python, and as a person who came to Python from other languages, I am a bit confused about the purpose of #property and its #xxx.setter brother. In Java and C++ get_xxx() and set_xxx() are usually the way to organize encapsulation. In Python we have these two decorators, which require specific syntax, and name matching in order to work. How is #property better than get-set methods?
I have checked this post and still, what are the advantages of #property besides the availability of the += operator?

The best part of using property for an attribute is that you don't need it.
The philosophy in Python is that classes attributes and methods are all public, but by convention - when you prefix their name with a single "_"
The mechanism behing "property", the descriptor protocol, allows one to change a previous dumb plain attribute into an instrumented attribute, guarded with code for the getter and setter, if the system evolves to a situation where it is needed.
But by default, a name attribute in a class, is just a plain attribute. You do person.name = "Name"- no guards needed, no setting method needed nor recommended. When and if it one needs a guard for that (say, to capitalize the name, or filter on improper words), whatever code uses that attribute needs no change: with the use of property, attribute assignment still takes place with the "=" operator.
Other than that, if using "=" does not look prettier than person.set_name("Name") for you, I think it does for most people. Of course, that is subjective.

Advantages of using static methods over instance methods in python

My IDE keeps suggesting I convert my instance methods to static methods. I guess because I haven't referenced any self within these methods.
An example is :
class NotificationViewSet(NSViewSet):
def pre_create_processing(self, request, obj):
log.debug(" creating messages ")
# Ensure data is consistent and belongs to the sending bot.
obj['user_id'] = request.auth.owner.id
obj['bot_id'] = request.auth.id
So my question would be: do I lose anything by just ignoring the IDE suggestions, or is there more to it?

This is a matter of workflow, intentions with your design, and also a somewhat subjective decision.
First of all, you are right, your IDE suggests converting the method to a static method because the method does not use the instance. It is most likely a good idea to follow this suggestion, but you might have a few reasons to ignore it.
Possible reasons to ignore it:
The code is soon to be changed to use the instance (on the other hand, the idea of soon is subjective, so be careful)
The code is legacy and not entirely understood/known
The interface is used in a polymorphic/duck typed way (e.g. you have a collection of objects with this method and you want to call them in a uniform way, but the implementation in this class happens to not need to use the instance - which is a bit of a code smell)
The interface is specified externally and cannot be changed (this is analog to the previous reason)
The AST of the code is read/manipulated either by itself or something that uses it and expects this method to be an instance method (this again is an external dependency on the interface)
I'm sure there can be more, but failing these types of reasons I would follow the suggestion. However, if the method does not belong to the class (e.g. factory method or something similar), I would refactor it to not be part of the class.

I think that you might be mixing up some terminology - the example is not a class method. Class methods receive the class as the first argument, they do not receive the instance. In this case you have a normal instance method that is not using its instance.
If the method does not belong in the class, you can move it out of the class and make it a standard function. Otherwise, if it should be bundled as part of the class, e.g. it's a factory function, then you should probably make it a static method as this (at a minimum) serves as useful documentation to users of your class that the method is coupled to the class, but not dependent on it's state.
Making the method static also has the advantage this it can be overridden in subclasses of the class. If the method was moved outside of the class as a regular function then subclassing is not possible.

Is there a way to ensure validation is performed on a variable than #property?

I'm writing a library that parses a file, creates an object that represents the file, and allows exporting the object back to a file.
I want to validate that the required headers and columns are included any time those values are changed. Due to this, I was trying to setup validation with the #property decorator.
I noticed in the python documentation for #property they use '_variable' if the property name was 'variable'. I understand that a single underscore in front is to signify the variable is intended for weak internal use. However, I was under the impression the point of the #property decorator was that any call to set a variable would cause the setter function to run.
_headers = None
required_headers = ['FIELD_DELIM', 'VIDEO_FORMAT', 'FPS']
#property
def headers(self):
return self._headers
#headers.setter
def headers(self, value):
for header in self.required_headers:
if header not in value:
raise Exception
self._headers = value
While this code works, I know that I can still bypass my setter by doing myObject._headers=value.
Is there a way I can ensure that validation is always performed without relying on a user to respect _headers is for internal use?

Python is not designed to help you "ensure" that nobody misuses your objects like that. The underscore prefix for private attributes, and the #property mechanism for hiding attributes behind getters and setters, can ensure that it's obvious that people shouldn't use your objects like that, and make it harder for them to do so accidentally, but it can't prevent them from actually doing so maliciously.
While there are tricks you can use to hide your attributes even better, in a highly dynamic, introspectable language like Python, there's always going to be a way to get around that—look directly in your __dict__, or in whatever other attribute you hide them in, or just change the __class__ of your object to something less restrictive.
In other words, you already can rely on a user to respect that _headers is for internal use if all you're worried about is your users being idiots; if you're worried about them being malicious, Python is the wrong language for you.

You can use double underscore for name mangling or implement a custom descriptor, but one of Python's core tenets is that users are expected to be "consenting adults" who respect interfaces and do their best not to do things that break interfaces without a very good reason. Basically, don't worry about it and just use the single underscore to store the data on the object.

sort of. there's no real privacy in python and with a little work a user can circumvent your privacy safegauards.
if you want, you could implement __getattribute__ which checks any time you try to access an element of your class, but even that's not foolproof. check out this link Difference between __getattr__ vs __getattribute__

No, Python doesn't enforce the concept of private vs public like Java does

Getter method vs read-only property

There already was a similar question "When and how to use the builtin function property() in python", but I thing this is one is different.
I have a class that needs a method to get a counter of some work progress:
class Downloader():
def __init__(self, max_workers):
self.executor = ThreadPoolExecutor(max_workers)
#property
def unfinished_tasks_count(self):
return self.executor._work_queue.unfinished_tasks
I think it's better to do:
class Downloader():
...
def get_unfinished_tasks_count(self):
return self.executor._work_queue.unfinished_tasks
because when it's property looking at the interface (without looking at the docs and/or source code) it is not explicit that it's a read-only, computed attribute. When it's a method it is clear that it is only a getter of a computed value and it's not a simple attribute that can be set by an API client.
So my question is: When to use a getter method vs a read-only property?

The usage of properties should bear your intention and provide a reasonable expectation to your peers.
When not to use a property:
When it involves a computation that may take non-constant time. This would counter the intuition that accessing an attribute is a fast thing to do.
When it bears some external state, that is changed by someone else than your peer accessing the property. Doing so would counter the intuition that accessing the attribute twice yields the same result. On the other hand when you need the result of a method call twice, you usually store it in a local variable and thereby avoid it changing in between.
When to use properties:
Mainly when not using properties becomes a burden (syntactically).
When you need to implement a particular interface (duck typing) and there is no other way to do it.
As usual with such questions, answers are subject to taste and there are no hard rules. These guidelines may serve you well in many cases, but they do not remove the need to apply common sense.

Static classes in Python

I once read (I think on a page from Microsoft) that it's a good way to use static classes, when you don't NEED two or more instances of a class.
I'm writing a program in Python. Is it a bad style, if I use #classmethod for every method of a class?

Generally, usage like this is better done by just using functions in a module, without a class at all.

It's terrible style, unless you actually need to access the class.
A static method [...] does not translate to a Python classmethod. Oh sure, it results in more or less the same effect, but the goal of a classmethod is actually to do something that's usually not even possible [...] (like inheriting a non-default constructor). The idiomatic translation of a [...] static method is usually a module-level function, not a classmethod or staticmethod.
source

In my experience creating a class is a very good solution for a number of reasons. One is that you wind up using the class as a 'normal' class (esp. making more than just one instance) more often than you might think. It's also a reasonable style choice to stick with classes for everthing; this can make it easier for others who read/maintain your code, esp if they are very OO - they will be comfortable with classes. As noted in other replies, it's also reasonable to just use 'bare' functions for the implementation. You may wish to start with a class and make it a singleton/Borg pattern (lots of examples if you googlefor these); it gives you the flexibility to (re)use the class to meet other needs. I would recommend against the 'static class' approach as being non-conventional and non-Pythonic, which makes it harder to read and maintain.

There are a few approaches you might take for this. As others have mentioned, you could just use module-level functions. In this case, the module itself is the namespace that holds them together. Another option, which can be useful if you need to keep track of state, is to define a class with normal methods (taking self), and then define a single global instance of it, and copy its instance methods to the module namespace. This is the approach taken by the standard library "random" module -- take a look at lib/python2.5/random.py in your python directory. At the bottom, it has something like this:
# Create one instance, seeded from current time, and export its methods
# as module-level functions. [...]
_inst = Random()
seed = _inst.seed
random = _inst.random
uniform = _inst.uniform
...
Or you can take the basic approach you described (though I would recommend using #staticmethod rather than #classmethod in most cases).

You might actually want a singleton class rather than a static class:
Making a singleton class in python