28 Feb 2018
When is a
bool not a
bool? In Python, of course.
You see, once upon a time (specifically the late 80s and early 90s), some guy named Guido started implementing a new programming language. One that would be pragmatic, uncluttered, and compact, yet highly opinionated. It’s a neat language, but not without its drawbacks.
Most of my day-to-day work is done in Python. Just yesterday I discovered a most interesting quirk of the language. Because Python is a duck-typed language, values of one type can be frequently interpreted as values of another type. In fact, some of this is by design. In the Python “days of old”, there wasn’t even a
bool type – just
int values of
What I was working with in my codebase was a bit of logic to read an optional config value, check if it was an
int (intending for
False as a value to mean that the config flag was disabled) and if so, act accordingly with that
Anyway, here’s an approximation of the code used:
def scrambled_subset(query, config):
if isinstance(config.QUERY_LIMIT, int):
query = query.order_by(fn.RANDOM).limit(config.QUERY_LIMIT)
# More implementation
There was more going on overall here, but that’s the gist of it. The intended effect? If there was a limit configured, limit the query to that many rows. The limit was in play for some time, but then the need came to remove the limit – so I set
False, thinking “welp,
False definitely is not an
So, there I was watching the consumer of that (so I thought) un-limited query have no rows to act on. What the what? So I did some poking around the code.
>>> isinstance(False, bool)
>>> isinstance(False, int))
So after a little bit more research, I found that Python’s
bools are totally acceptable
ints. They even have prescribed values:
>>> False + 1
>>> True + 1
>>> 2 ** (True + 1)
>>> 2 ** (- True)
>>> 2 ** False
>>> False ** 2
So there you have it, folks. In Python, a
bool is really just a fancy fucking
12 Feb 2017
Working on your main work all day might fulfill some people entirely, and to be honest, it fits the bill most of the time for me. Sometimes, though, I want to do something else, but to do something more than just rot and watch TV. My main hobby of choice is cooking. I’m hoping I can expand on other hobbies in the future and explain what they mean to me.
But you’re a weird programmer why do you like food you should just drink Soylent right?
Lots of engineers will admit to liking cooking (though the common opinions and assumptions about engineers might indicate otherwise) if you ask them. I think it’s a great escape from a work of precision and discrete implementations. While recipes are important (and precision can come into play, particularly in the realm of baking) cooking appeals to me because I have more leeway in how I’m going to operate; it’s one of those “the journey matters as much as the destination” things, unlike much of the programming world.
I love having a basket of new ingredients in front of me, and to consider how they might play together. All my life I’ve been interested in strange combinations of flavors (too strange – in a bad way – for the mainstream pallette, or so I would assume), and so finding discipline for those interests by way of formal cooking has been nice.
So, pizza, then?
As you, savvy reader, may have seen on this blog before, one of my favorite things to cook is pizza. Some folks are very particular about how they do their pizza. Namely, precision in the composition of a dough. I’m a little more freewheeling than that, and I just like to eyeball the right amount of yeast and sugar, water and flour, etc. It’s an experiment, but not the kind of rigid, well-organized experiment you’d have in a lab. More like a toddler experimenting with a puddle of mud.
I like being that toddler, at least in the kitchen. When I’m cooking, everything is new to me, every time. Every steak is going to sear differently. Every batch of cookies is going to have its own character. Clearly that wouldn’t work well in a commercial kitchen, but at home it’s great fun.
If you love it so much, why don’t you marry it?
My spouse has asked me a number of times whether I would prefer to quit my job and go to culinary school. Perhaps, one day, I will. But then I wouldn’t be having the same fun. I wouldn’t be experimenting as much. Who knows, though; my opinion will likely change in the future.
Cooking isn’t just for you, of course, either. Sustenance is one of the core requirements of caring for a human being. At its most basic (and perhaps sardonic) level, cooking for someone is demonstrating that you value their existence and wish to continue it. It’s an example of deep caring for someone else, I believe, and I make sure that I keep that in mind as I prepare any meal, for any group of people.
My advice to anyone learning to cook
- Approach the kitchen with curiosity.
- Watch the entirety of Alton Brown’s Good Eats
- Don’t take yourself so damn seriously. Your food is gonna suck.
- Watch a bunch of You Suck At Cooking
- Work on your knife skills first and foremost. Good knife skills make prep work a lot more fun. There’s a Good Eats episode that teaches a lot of knife work and care. Find it.
- Remember that the end result of messing up most likely will still taste great. Don’t sweat the presentation until you’ve got it tasting awesome.
- Try to make time to explore the produce and butcher sections of your supermarket, or better yet, visit a local butcher shop and farmers market to see what’s fresh and tasty.
- Whenever you cook, think to yourself about ways you could change it in the future. Recipes are a starting-off point, not a gospel
- Put your love (figuratively, please) into your food. It’s cheesy but people respond to it.
Thanks for reading. Hope I can ramble more on the subject soon.
05 Feb 2017
Fifty years ago, on January 27th, 1967, three astronauts died in a fire aboard the capsule that would have been Apollo I. During a routine preparation test, a short circuit in their computing machinery ignited inside the capsule’s all-oxygen pressurized environment, leading to an immediate fireball engulfing the cabin within seconds. Simply put, this accident was avoidable and caused ultimately by the haste of the NASA personnel designing the Apollo program.
Earlier missions in NASA’s Mercury program exposed the risk involved with having a mixed nitrogen/oxygen atmosphere inside the capsule: more complex machinery to provide both gases and the risk of astronauts experiencing decompression sickness (AKA the “bends”). Surprisingly, NASA officials admitted they hadn’t considered the impact of a 100% oxygen environment on fire risk.
Additionally, the Apollo capsule’s interior was not designed with fire mitigation in mind, as the review board found after the accident. Wires throughout the capsule were not adequately shielded. Combustible materials were placed near heat sources without caution. Lastly, the capsule’s liquid cooling system, prone to leaks, used a solution that reacted with the highly-oxygenated atmosphere of the capsule in an exothermic nature.
The Space Race had NASA cutting corners wherever possible to get their astronauts strapped onto a rocket and shot into the sky. Communication and caution in these cases would have saved lives. Instead, our ambition as a nation wasted them.
Thirty-one years ago, seven of America’s bravest men and women perished on their journey to the stars. Their journey ended, tragically, just minutes into their flight aboard the Space Shuttle Challenger, as the orbiter, its external fuel tank, and solid rocket boosters violently exploded in the Earth’s atmosphere.
The late Dr. Richard Feynman, renowned physicist, traveled across the country to find the answers as part of a Congressional commission.
Not to spoil the linked excerpt from his memoir, but actually this pretty much spoils it: he ultimately found that pressures to launch on time forced management at a contracted aerospace company to ignore and sequester their engineers’ concerns that the material of which the shuttle’s solid rocket booster’s sealing O-Rings would not perform to specification given the unusually cold weather at the launchpad the morning of the launch.
The failure of these O-Rings allowed for highly-pressurized, super-hot combustion artifacts to leak from the starboard solid rocket booster. This plume burned a hole in the external fuel tank (the big orange one), which suffered a catastrophic failure ultimately resulting in a very large explosion and disintegration of the entire vehicle.
Fourteen years ago, seven more of our nation’s selfless explorers were lost. The Space Shuttle Columbia broke apart on atmospheric re-entry on February 1st, 2003. Pieces of the shuttle, including personal equipment of the astronauts, were found strewn about Texas and Louisiana.
It was discovered after investigation that a piece of insulation foam from the external fuel tank struck the leading edge of the orbiter’s wing, damaging it and leaving it susceptible to high-temperature gas entry during re-entry. These high-temperature gases entered the internal structure of the wing and effectively destroyed it.
During Columbia’s orbit, concern was raised over the condition of the wing by engineers on the orbiter team, but their concerns were responded to with callous disregard for human life: “You know, there is nothing we can do about damage to the TPS [Thermal Protection System]… Don’t you think it would be better for them to have a happy successful flight and die unexpectedly during entry than to stay on orbit, knowing that there was nothing to be done, until the air ran out?”
Headstrong pushes for achievement over careful progression, as well as failure to address legitimate concerns from the people actually doing the work have cost the lives of several astronauts. These were all preventable accidents, if only the individual contributors were trusted as much as the top brass.
Without skilled, patient, and disciplined scientists, we are doomed to repeat our own failures, at the cost of our fellow humans’ lives. This is why support for a thriving scientific community is critical to our nation’s well-being and safety.
13 Aug 2016
Ever come across a Python library with some kind of shortcoming that you know you can fix, but don’t want to fork, fix, pull-request, wait five weeks, then update in order to get moving? Are you even too lazy to do just the first two steps and point your dependency manager at your own fork? Don’t worry, you can probably fix it in code.
Right now I’m writing a Slack bot library that will support, in addition to the commonplace single command/response paradigm, a more conversational paradigm for multi-step commands and workflows. So, like a good programmer, I set up my module structure, my
setup.py, and got moving. This was after a little bit of proof-of-concept code sketching, in which I came up with the general flow of connecting with the official Slack client for python, aptly named
python-slackclient. So, I ported the flow into my library’s code, with some nicer structure, fired up a
python setup.py develop, and then wrote a little wrapper script to invoke the client.
Boom, error. Weird, right? My proof-of-concept had worked fine…
After looking at Slack’s code, I found that it was cleansing an exception from the
websocket-client library, where it was having problems locating my system’s Root Certificate Authority file. That’s a problem I don’t really want to deal with right now. I have a feeling it has to do with the path magic that
python setup.py develop does, so I’m willing to let it go. Nonetheless, I’m still stuck with it not working, and no way to tell the Slack client to get its head out of its ass and find the Root CA file for the websocket client.
Or is there?
create_connection takes a URL by default but also takes some
kwargs, one of which is
sslopt, a dictionary of values describing SSL options, including the location of the Root CA file. Additionally, the
ssl standard library includes methods for retrieving the location of said file. But, again, the calling of
create_connection is within the Slack client’s code! What do I do?
Swizzle that shit!
Swizzling, for the uninitiated, is the same thing as monkey-patching, which is to say, replacing at runtime the implementation of a method on a class. Alas, it’s a little more complex in this case, since the method I want to swizzle is on the class of an object, an instance of which is held by the Slack client. So, I ended up using a subclass of the client and overloading the initializer to dig into the client’s state and swizzle the method in question.
Check it out!
Note that you have to bind the newly-defined method to the class, meaning that if you only have a reference to an instance, you need to use the
__class__ attribute to get the class itself. Don’t forget
self as the first argument; this is important for the method to bind correctly to the class/instance.
Oh, so, by the way, that Slack bot library I’m working on can be found here: SlackBorg.
02 Jul 2016
Time for another pizza! This one was a lot of fun, mostly because it was so briny and tasty. If you like salty stuff, this pizza is for you.
Olive Bomb, Before
Olive Bomb, After
- Pizza dough (again, I’ll be posting a recipe to this soon!)
- Some kind of herb (I had parsley)
- Anchovy paste
- Olive Oil
- Garlic cloves (one or two) sliced very very thin.
- Kalamata Olives, pitted, then sliced or chopped
- Castelvetrano Olives, pitted, then sliced or chopped
- Mozarella Cheese (I use Belgoioso gems, but any mozz will do. Stay away from very wet varieties)
Preheat your oven and pizza stone/steel as high as it goes. Finely chop up your herb of choice, and whip together with your olive oil and anchovy paste. If you omit the anchovy paste, probably add a little salt. Let sit for a little bit while you spread/toss/roll out your dough into your pizza shape. Give your dough a nice massage with your finger tips – just poke and poke with your outstretched fingers, until the surface is full of depressions like a golf ball. Spread your anchovy herb oil over the crust. Evenly distribute your cheese and olives. Throw that in the oven and bake until you’ve got some nice brown on your crust.