See, Python has a fun interpretation of scoping. Let’s say I define a variable and a function at the same level, then access the variable from the function; the function will read the variable just fine. This is because Python looks for the variable in the current scope, then bumps up a scope level, looks again, etc. until it finds it or runs out of scope.

my_var = 'abcd' def my_func(): print my_var my_func() > "abcd" 

However, things change when you write to...
READ MORE

It’s never easy saying good bye. Sometimes you see it coming, sometimes you intuit that it’s going to happen, and sometimes it smacks you out of left field. Today’s departure was of the smacking variety.

While this is less the project being blatantly axed and more the project being put on hold (at least, that’s the messaging), I’ve only seen one project come back from the shelf, so I don’t hold high faith for this one. I’ll be doing the best I can to spend a cycle or two on it to keep it up to date - you know,...
READ MORE

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

If you’ve followed the tech world as it pertains to start-ups and code deployment strategies, one of the buzzwords you may have heard is “service-oriented architecture” or “SOA”. You can get quite a lot of hits doing a Google search for those terms - assuming that you ignore all the Sons of Anarchy links, of course.

Significantly cooler than the SOA I deal with

It’s one of the hot topics nowadays, in line with things like “Agile” and “Hadoop” and “funded”. At my work, we’re using SOA as well; in fact, I’m...
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