Some of you may know that Apress contacted me a little bit ago, wanting to publish my book under their brand. Well all the work is done now, and the book is up for sale on their web site, and soon it will be up on Amazon!
So go add the book to your wish lists!
Thanks for all your support, everyone. If I didn’t have a decent following, I’m not sure I would have written the book in the first place.
P.S. My second video is recorded. I just need to do some editing, and it will be put up soon.
Making Descriptors that act as specialized properties can be tricky, especially when it comes to storing the data the property controls. I should know, I literally wrote the book. Looking at how other languages do it – especially Kotlin’s Delegated Properties – I felt that Python could use a system that works more like that. Continue Reading
So here’s my attempt at accomplishing the closest thing possible toward making object literals in Python. Continue Reading
It’s time that I got a bit more real with you guys. Pretty much ever since I learned Python, I’ve been touting it as a super amazing language. I’ve been doing the same with Kotlin, but this is about Python.
Now, this doesn’t mean I’m going to be changing my tune from here on out; after this, I’m not really going to bringing up the weak points of Python. I’m just going to continue talking about strong principles, practices, features, and tips and tricks. But this article was just inspired by a small revelation, and I decided to just roll with it.
That inspiration was due to the revelation that the official Python logo looks vaguely like a yin yang symbol (apparently, it’s called the Taijitu). To prove it, I made an alteration to the symbol, changing just the colors.
So, let’s look at the pros and cons of Python. Continue Reading
Today, I give you the second (and last) excerpt from my book, and it’s the last chapter. It brushes over some of the cooler examples of descriptors out there. It’s a short sample, and I feel kind of bad not giving you something juicier, but too much of the rest of the book has references to other chapters and discussed ideas, making it difficult to use as an excerpt. Continue Reading
Last week, I posted that I would put up some excerpts from my book, Python Descriptors: A Comprehensive Guide, this week and next week. This is the first of two.
This chapter of the book has one of my greatest epiphanies in it: “unbound attributes”. For context, I decided to provide the entire chapter here, instead of just putting the excerpt about unbound attributes in. Despite the context, this chapter assumes you at least know the descriptor protocol and its basics. If not, check out Raymond Hettinger’s relatively short article on descriptors. Enjoy! Continue Reading
Python descriptors are a fairly powerful mechanic, especially for creating properties. The built-in
property descriptor/decorator works very well for defining properties, but they have a small weakness in my eyes: it doesn’t have defaults for simple usage. Yes, not supplying the property class with all methods does have the decent default of not allowing that usage, but I mean that it doesn’t automatically implement some form of backing field. Backing fields are done completely explicitly by you.
This is not a problem in some cases. In fact, it makes the property class exceptionally versatile, but at the cost of my explicitness on the part of the user. It has its uses, and it’s great at them. But I have need for something a little less versatile, more specialized, and more implicit.
I strongly try to make as many of my classes immutable as possible, avoiding side effects. Because of this, I want my class attributes to be read-only. There are two existing ways to deal with this. The first is to simply document that I want the attributes to be left alone. This is valid, and has a sort of simplicity to it, but sometimes I like to back up those intents with something a little more restrictive. The second option is to use a
property without defining a setter. This is actually a very good option, but as I said while leading up to this, it’s highly explicit. I want a property that is designed for the express purpose of being read-only. Continue Reading