loading...

Dead Simple Python: Classes

Jason C. McDonald on January 19, 2019

Classes and objects: the bread-and-butter of many a developer. Object-oriented programming is one of the mainstays of modern programming, so it sho... [Read Full]
pic
Editor guide
 

I read a really funny analogy for why python’s private-ish variables are good enough and we don’t have stricter access control:

I’d like you to stay out of my living room because I ask you to, not because I have a shotgun!

Thanks for the article!

 

I'd like to add that you should mention that there's pretty much never a good reason to use staticmethod as opposed to a global method in the module.

Usually, when we write a module, we can simply write a method outside the class, to get the same behaviour as a staticmethod

 

I try to avoid such statements, especially in this article series. If it exists, it exists for some reason. ;)

That said, I plan to discuss the ins and outs of this in more depth in the book.

 

Ah I see! I really appreciate this series. It is very well written and enjoyable to read!

By the way, what is that reason?

 

Thanks for the excellent Article.

Some small suggestion: in the setter example the actual line of code that sets the Instance Member self.__captain = value is missing ;-)

class Starship:
    def __init__(self):
        # snip
        self.__captain = "Jean-Luc Picard"

    @property
    def captain(self):
        return self.__captain

    @captain.setter
    def captain(self, value):
        print("What do you think this is, " + value + ", the USS Pegasus? Back to work!")

uss_enterprise = Starship()
print(uss_enterprise.captain)
uss_enterprise.captain = "Wesley"
print(uss_enterprise.captain)

Resulting in this output, Jean-Luc Picard refuses to go away....

uss_enterprise = Starship()
uss_enterprise.captain
>>> 'Jean-Luc Picard'
uss_enterprise.captain = "Wesley"
>>> What do you think this is, Wesley, the USS Pegasus? Back to work!
uss_enterprise.captain
>>> 'Jean-Luc Picard'
 

Awesome coverage of classes in Python! Kudos to showing how to set properties using getters/setters. When I first learned python, I did not understand this and would create my own def to modify a property on my instances. Very fun, Next Generation is my favorite Trek series.

 

@staticmethod
def make_sound(cls):

Should cls be passed into a staticmethod? I thought that was only for class methods

 

I cannot believe it! I actually missed that little detail: @staticmethod and @classmethod are actually two separate things!

I've just edited the article to correct that, and added a new section to clarify the difference. Thank you so much for correcting that.

 
 

Nice, properties, getters, and setters all explain some things I had never even seen or thought of before (Python being my first programming language), it definitely expanded my understanding of what a class is and can do.

 

Great article! Python is neither my primary nor my secondary language, but I've been using it a lot for my grad school work. I realize how naive my own Python code has been after reading your post haha. Do you have any suggestions for more material like this to learn the best practices? I have found that the python docs are not the most captivating. Thank you for this post! Great job.

 

Unfortunately, I haven't found much! That's precisely why I started this article series.

If you have some extra cash laying around, you could sign up for Udemy: The Complete Python Course by Codestars. He covers good practice pretty well. However, it is unfortunately quite beginner-oriented, so it's slow going at first.

 
def engage(self, factor):

in the subtopic Methods should be

def warp(self, factor):

as engage has no parameter factor

 

Another great catch. Thank you!

 

In inheritance, what if we do not write 'super().init()' in child class' init() method? Does child class not call it by default?

 

No, it doesn't, as far as I know. As mentioned in the Zen of Python, Explicit is better than implicit. It's part of the language philosophy.

We often need to handle passing data to the parent __init__() in a specific way, and we may need to do some other things first, so Python just assumes we know best how to handle that.

Imagine how maddening it could get if Python sometimes called it for you, but sometimes not! (Some languages actually are confusing like that, but Python aims to be obvious.)

 

Thanks for clarifying!
It would be very helpful if you also explain MRO (Method Resolution Order) in context of Python 3 in any upcoming series.

 

This was a very clear and well-written article, probably one of the best that I’ve read regarding Python classes. Thanks!

 

Nice article Jason. Keep writing more.

 

Thanks for writing this article.Jason

 

Thank you for great article!
Just one thing, you have a typo in your example "engine_strain" as @property. It should be "elif" instead "else if".

 

Thanks for catching that!

 

instance variables shadow (hide) the class variables,

Not quite. The class variables are shadowed; instance variables eclipse, as they dominate.

Good article, thanks 😎

Code of Conduct Report abuse