In the Field system I built with Python (covered in the Field Encapsulation Pattern series of posts, found here), I ended up coming across an interesting problem. I thought I’d post my thoughts on this issue and how I ended up solving it.

As a quick recap, the system defines classes which are definitions of fields on a data model, representing the rules on how to store, represent, and validate, say, a date, a url, etc. Each of these fields will have a list of validation rules that it has to meet. An example of this is an IntegerField...
READ MORE

So, I came across something pretty interesting while coding in Python today. I was writing a system in which I have to pass a function as an argument to be called later; a.k.a. a callback. I’ve done this in a lot of different contexts in languages like Python, PHP, JavaScript, Java, and ActionScript, so that’s why I was taken aback by my experience today.

I have one class which takes a function or a list of functions for calling later; the signature of the function will look like this:

We’re here! To now, we’ve come through part 1, part 2, part 3, and part 4, and now we’re ready to wrap it up. So, without further ado, the conclusion to the Field encapsulation pattern!

Where are we?

At this point, we have field objects, we have validation functions, have required, we have read-only. What’s left? Flashing back to the requirements, we need a serializable representation and a default value. Let’s throw those in!

Serialization fun

I use json. A lot. It’s cross-platform, easy (enough) to read, has far less bloat than XML, and...
READ MORE

Here we are in the fourth portion of our trek to create a field encapsulation pattern in Python! For previous legs of our journey, you can try here, here, or here. Otherwise, let’s kick it off!

Where are we?

By the end of our last meeting, we had made pretty good progress. We’re able to type fields on an object, mark them as required so we must provide their values when creating said object, and mark attributes as read-only so we can’t change them after the object has been created.

But, before we go any further...
READ MORE

Welcome back to creating a field encapsulation pattern in Python! As you may be aware, this is the third installment in the series. To catch up, you can read part 1 and part 2; I’ll wait. Ready? Let’s go!

Where are we?

First, let’s review the requirements for this project:

1. Type safety: we need to be sure that an attribute is of a defined type
2. Required: we need some attributes while others are optional
3. Read Only: certain attributes should be read-only
4. Serialized representation: during serialization, we need to convert the unserializable value to one which can...
   READ MORE

This is part 2 of a detailed series on my implementation of a field encapsulation pattern, continued from part 1. If you recall from the last time, we introduced the idea of getters and setters, properly called “properties” in Python. If you don’t recall, please take a moment and hit up part 1 before going on. Now, here we go!

Where we left off, we were able to protect our attribute by using decorators to create a getter and a setter which will protect the field from bad values. Here’s what it looked like at the end of...
READ MORE

Some background

At work, we’re currently spooling up more and more Python, which I think is great! I love working with Python. However, with this shift, we’re moving away from an ORM framework in PHP which had things like attribute validation, and we’re not using one in Python which does the same. So, now I’m up against validating in a dynamically typed language efficiently and with the least amount of code possible. The thing with a dynamically typed language is that you can assign whatever value you want to whatever variable you want; if I want attributes of this...
READ MORE