Python

I taught a tutorial at PyCon a few days ago. It went well, but what I want to discuss are some technical things I did that went well and (I think) made the presentation easier for students to follow.

This post is a followup to my article The Basics of Exceptions in Python, but should make sense on its own as long as you are familiar with raise and try/except.

Let’s cover a few more advanced aspects of the Python exception system. We’ll move a bit faster and talk at a higher level than we did in the last post.

Topics we’ll hit:

• More Python Built-in Exceptions
• User-defined Exception Classes
• Finally Blocks
• Keeping try Blocks Small

This post was originally meant to be a small part of my discussion of the Go programming language (coming soon) as a way of drawing contrast between Python and Go, but turned out to be extensive enough to justify its own post.

Python’s model of exceptions is quite similar to that of other popular object-oriented languages like Ruby, JavaScript, and Java¹. Errors flow differently than regular data; if not “handled”, they rise up through the entire function stack and crash the program. Developers are encouraged to write code to anticipate those exceptions, handle them before everything explodes, and change the logic flow of the program accordingly.

What exactly needs to be done in that “handling” step typically depends on what went wrong, and so there are many types of errors. Programmers can check the type of an error to determine what went wrong and react accordingly. Errors can be thought of as objects and their types as classes that can be subclassed like any other class. But unlike other data, they follow an error-specific path through the code, short-circuitiing functions all the way up the stack until handled.

I went to PyCon a few weeks ago and while there, saw Peter Wang’s keynote on a new project called PyScript. PyScript is, essentially, a set of tools for running Python code in the browser – potentially even user-submitted code. I think that’s going to have a significant impact on the Python world, though maybe not in the way you’d first expect. Some Background For years now, various groups have been working on finding a way to “run” Python in the browser.

I recently crossed the 9-month mark as a Chicago resident. The time has come for a big decision: renew my lease, or make the move to a new apartment?

I really like my current home. Two bedrooms, a back porch, a garage, and more grounded outlets than even a tech nerd like me could want. It’s in Little Italy, which is not a popular choice for Chicago young professionals, but is comfortable and has a decent set of restaurants. I suspect that a similar unit in a more “hip” neighborhood might be out of my price range. And my real office (as opposed to my extra bedroom, which has been serving in that capacity since I moved here) is a 10-minute bike ride away. The north side, home of many of those hip neighborhoods, would bring with it a commute at least twice as long.

On the other hand, my primary motivation in moving to a big city was exploration and experience. I wanted to get to know Chicago, particularly its neighborhoods. Moving would offer me a change of location, unlocking many new walkable or bikable destinations. Additionally, none of my friends live near my current apartment; most are in various parts of the northern neighborhoods, while I live somewhat south and west of the Loop (the downtown area of Chicago). Seeing most friends requires a 15+ minute drive or 30+ minute train ride.

For a while now, I’ve been thinking about how interesting it would be to look at data on my running habits. Depending on the time of year and some other factors, I probably run 1-4 times a week, and I’ve been running semi-regularly since college.

For the vast majority of that time, I’ve recorded my runs in Under Armour’s MapMyRun app. It’s a bit buggy and feels non-native, but it has a good Apple Watch app and collects the information I need fairly reliably.

My colleague Brad Boehmke and I made a guest appearance on the Talk Python to Me podcast to talk about the challenges of supporting a large data science department that uses both R and Python. You can listen to the episode on any podcast player.