All posts containing the 'python' tag
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
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:
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!
I use json. A lot. It’s cross-platform, easy (enough) to read, has far less bloat than XML, and...
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...
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:
- Type safety: we need to be sure that an attribute is of a defined type
- Required: we need some attributes while others are optional
- Read Only: certain attributes should be read-only
- Serialized representation: during serialization, we need to convert the unserializable value to one which can...
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...
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...