I was looking through some of my old posts, and started reading one that I wrote for Java, and I just didn’t like it. So, I’ve decided to go through and rewrite a bunch of the old posts (I’ll keep the old ones as they are), updating them to Kotlin. In some, I may even put the old Java code in just to show how much nicer Kotlin makes it.
I’ll try to get the Java/Kotlin version of the DocRaptor article written soon. Also, I’m in talks with another website to write paid posts for their blog. If I get to, I’ll share links to the articles I post there.
I’m also in talks with Apress to write a second edition of my book, Python Descriptors. Changes will mostly be adding content on the
__set_name__() method added to the descriptor protocol in 3.6 as well as a full chapter on my instance–level properties idea. Other than that, I’ll be going through and just cleaning up the writing in general if I spot anything. I’ll probably also simplify the flow charts. At the same time, I’ll be putting together a talk on Python Descriptors that I hope to give at That Conference this year.
Overall, I’m feeling the push to get back to writing. Hopefully, I can keep up with it.
Some people have spoken against Kotlin’s decision to make classes, methods, etc. public by default (when no visibility modifier is used), and I would just like to pitch in on why I think JetBrains made the right decision on this one. Continue Reading
Man, I’ve had this idea in my head for more than a month now (luckily I wrote it down, too), waiting until the day I wrote this post. I didn’t write it because I was busy with the move and new job, but now things are finally settling down!
Here’s the thing: When you really dig into it, proper object-oriented programming and functional programming are pretty similar. The biggest difference is that object-oriented programming likes to use encapsulation to hide the real data behind facades of objects – requiring you to define methods attached to the type that know about private details – while functional programming is quite up front about it all – making it so that you generally get switch-like structures (but WAY better) that allow you write one function to handle all of the different types. Continue Reading
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.
Recreating Kotlin’s Built-In Delegates
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
__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
Well, my Watch Later playlist on YouTube is extra full now! A bunch of videos from really big programming conferences have just dropped.
PyCon 2017: 144 Videos!
Google IO 2017: 158 Videos!
Now, obviously not all videos are going to interest everyone, but there’s something for just about any Python programmer in the PyCon list, and I only went through the Android videos for GoogleIO and I got 10 videos added.
With Google IO came a really cool announcement for Kotlin-Android developers, too: Kotlin is now getting first class support from Google for Android!