Last week, I showed you my new implementation for instance-level properties in Python. This week, we’ll take another look at it by implementing a few Delegated Properties and helpers to make using them just a hair nicer.
For inspiration of what Delegated Properties to create, we’ll start by recreating the ones built into Kotlin, starting with Lazy. Continue Reading
A while back, I did a post on making instance-level properties in Python where the implementation of it required inheritance as well as messing with __getattribute__() and __setattr__(), which are a little dangerous to mess with. Then I had another idea last night (as of the time of writing this): Use normal descriptors to delegate to “Delegated Properties” (name taken from Kotlin, the original inspiration). These Delegated Properties can be designed very simply in a way that they only have to worry about the value on one instance, instead of figuring out how to store the value per instance. Continue Reading
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
In this, the fourth and final post in the Kotlin Month series, we take a look at a widely overarching feature of Kotlin that is tightly coupled with a few other features: Properties. Besides the obvious benefits of properties that they provide in all languages, Kotlin has reusable properties via Delegated Properties as well as really clean syntax for distinguishing between read-only and full properties. 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
