Home » Python » Better Unbound Python Descriptors

About Jacob Zimmerman

Jacob Zimmerman
Jacob is a certified Java programmer (level 1) and Python enthusiast. He loves to solve large problems with programming and considers himself pretty good at design.

Better Unbound Python Descriptors

Welcome back from another hiatus! This post is a facepalm post because I recently realized that I’ve been an idiot for so long. I have a tendency to make things more complicated than they need to be, as can be seen in my articles about instance properties.

I’ve briefly mentioned unbound attributes (Class.attr returns a function that you pass an instance into to look up the the value of that instance’s version of the attribute) with descriptors a time or two and they always ended up using a whole new object to represent the unbound attribute. In the example given, I returned a local function to use as the unbound attribute; in the descriptor-tools library that goes along with the book, I implemented it with an UnboundAttribute type, which allowed it to easily carry extra data (such as the descriptor object reference); then I discovered attrgetter in the operator module, so I substituted that in instead. But there was one big obvious solution I was missing.

Some Background

When implementing the __get__() method of a descriptor, the convention was to always return the descriptor itself if an instance was not given. When I started espousing using unbound attributes instead, I always had one caveat: since the convention for so long has been to return the descriptor, it can go against the Principle of Least Astonishment to return something else. So, I always advised using it with a grain of salt.

But I myself didn’t care; I had no real use for returning the descriptor. Really, the only thing that bugged me was that we had to create an object that had barely any use. I really love the style of having lots of small classes doing their things and letting the runtime largely deal with the repercussions, but it always hurt a little bit inside, since this object seemed like a waste.

Good News!

Well, after all these years, I’ve finally realized how much of an idiot I am and that none of these issues have to be issues at all!

The solution? Return the descriptor and give it a __call__() method that takes in the instance and delegates to the __get__() method, as shown:

class MyDescriptor:

    def __init__(self, …):

      ...

 

    def __call__(self, instance):

        return self.__get__(instance)

 

    def __get__(self, instance, owner=None):

        if instance is None:

            return self

        else:

          ...

This also finally gave me a good excuse for using the default value of None for the owner parameter!

But…

There is still one caveat to this version of an unbound attribute. If the descriptor has another use for __call__(), then using it for this either requires changing the unbound attribute to return some other implementation (one that allows the user to get access to the descriptor, or else having the __call__() method is useless) or you’ll have to use a normal method instead of __call__() for that use case.

Outro

As always, the KISS principle (Keep It Simple, Stupid) prevails. Not only is it simpler in almost every way, but it even makes it so you can ignore all the likely problems.

Updates

Remember how I said I’d rewrite a bunch of Java articles using Kotlin and/or Python? I haven’t even started that. And I probably won’t do that for a while, if ever. I feel bad, but my blog has simply not been a big priority to me for a while. I want to get back into doing it regularly, but that’s not likely. I have another article I’ve been wanting to do for a long time, but I really don’t feel like writing it because it’ll be a lot of example code, and example code always ends up being a hassle with my workflow.

I recently lost my job, so right now I’m focusing on padding my resume with projects and finishing all my planned updates to the descriptor-tools library (which is what inspired this article). Maybe the other projects will do the same thing. I also plan to work on a video for Apress (the publisher of my book) that take some of my book’s content and put it into video form. I may even touch on this article’s topic in those. I’m still not sure what it will be about, but some supplemental income will be nice.

Published on Web Code Geeks with permission by Jacob Zimmerman, partner at our WCG program. See the original article here: Better Unbound Python Descriptors

Opinions expressed by Web Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Web Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. Building web apps with Node.js
2. HTML5 Programming Cookbook
3. CSS Programming Cookbook
4. AngularJS Programming Cookbook
5. jQuery Programming Cookbook
6. Bootstrap Programming Cookbook
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of