Skip to content


OpenSCAD Import System: A Proposal

Having recently acquired a 3D printer, I've been diving in to 3D modeling. While Fusion 360 seems to be the leader in that area generally, I've fallen for OpenSCAD. I appreciate its use of code as the primary (read "only") design environment because it mirrors the way I tend to think about problems. This has the added benefits of making parametrized models being a core feature instead of an afterthought, and readable diffs for files under version control with git.

Over the past few days I've been working hard at reaching competency with OpenSCAD and have come to the point where I feel like I'm able to offer an informed perspective on some of its strengths and limitations. The biggest "rough edge" I've run into thus far is dealing with imports.

Ruby's Inequality Operators

My annoyance of the day in Ruby: inconsistent usage of the inequality operator in the standard library.

The generic inequality operator in Ruby throws an exception when objects of differing types are compared. This, in my opinion, is a good thing. I don't want to accidentally attempt to compare an integer and a class, for instance.

1 < Class
## ArgumentError: comparison of Fixnum with Class failed

This makes sense!

Today, I discovered that the inequality operators are overridden for classes and modules to allow for checking inheritance:

Testing for the existence of a Flask request context

I just finished reviewing a pull request that contained an extraneous statement inside a try block.

Here's the code in question:

    if signature not in g._celery_tasks:
except RuntimeError:

While this code works fine, the RuntimeError being caught is expected to be raised when g._celery_tasks is accessed. Because g is a werkzeug.LocalProxy object, the exception is raised if there is no active request context. My concern was that if the next line raised a RuntimeError, it would also be caught. As this is not the intent of this handler catching such an error would be unexpected behavior.

Reproducible Python Environments

I've spent the last couple of days looking at conda, a Python environment manager built by Continuum. In their own words, conda is "git branching for site-packages, combined with yum for Python packages." As I understand the project, it's actually quite a bit more than that.

Git Has Annoyed Me

I love git. Seriously, it's changed my life - before I used git, I was using Microsoft's Visual SourceSafe. Those were dark days indeed.

Git is probably the most well-though-out and consistent tool I've ever used. Innumerable developers around the world use it, from Linus hacking on the Linux kernel to a guy on Github submitting his first pull request. It's mature.

When you reach so close to perfection, the smallest issue seems much larger than it is. I think that's why this bothers me.

The Future of Python is in the Past

This post is in response to Calvin Spealman's I Am Worried About the Future of Python.

First, I believe that Calvin's concern is a legitimate one. Python has grown into one of the premier languages in the Open Source communnity - and for good reason. Python is designed from the ground up to support object- oriented development, and the conventions and syntax strongly encourage clean, readable code. It also has an excellent developer community, which is both supportive and uniformly knowledgable.