If you program, you create interfaces. And I don’t just mean the graphical user ones. All software is broken up in functions, methods, modules, plugins, etc. All pieces of software are used by other pieces of software. Every programmer’s code is used, sooner or later, by oher programmers. In the very least, it is used by himself. Also your future self, and your future self may not necessarily understand you as well as you hope. And why not make other programmers’ life, or your own life, easier, with better API design? Faster said than done, obviously, and I have a world to learn, I know that. Not going to happen overnight, though. All I can do is improve a little bit every day. And this EuroPython2011 conference has helped me start understanding the importance of that effort.
Application programming interfaces, also known as APIs, are everywhere. Google even has an API for APIs, and don’t call it meta. And application interfaces certainly were everywhere at this year’s EuroPython conference in Florence.
Alex Martelli‘s talk on good API design opened the conference, and Raymond Hettinger followed on the second day with his explanation of API design and the lessons learned. The API acronym kept showing up in titles, including Ali Afshar‘s “Latest advances in the Google APIs platform” and Johan Euphrosine‘s “Web API Mashups in a Python Application“. I missed out on “An iPhone-Python love affair: Building APIs for mobile” by Anna Callahan and Nate Aune.
Other talks didn’t have the word API in the title, but the subject could be read in between the lines, like at the Design Patterns talk by Alex Martelli (as Anna Ravenscroft noted, the Facade pattern was very API like). Or when Raymond Hettinger changed our view of Subclassing. And Wesley Chun talked about creating your own types that act just like Python types. The ZeroMQ talk by Francesco Crippa made me think about giving my applications a better way to talk between themselves (ZeroMQ is to sockets as Python is to C++, apparently).
Sad about having missed all of that? Don’t be! Watch the videos. Click on the title at the Schedule website, and watch. As easy as that! For some of my notes, click “Continue reading”.
I’ll use my tweets from EuroPython and my paper notes to help me put this post together.
“Alex Martelli API anti-patterns,avoid: No API. No design, API just happens. Wrong/no documentation. Lang specific data exchange #EuroPython“
If worrying about not being able to make a good API is paralyzing you, take Martelli’s advice: the worst mistake is no API at all. Because APIs just happen anyway, you can’t prevent that. So it’s best to plan. Same applies to documentation. If you don’t like writing documentation or are nervous about not doing a good enough job enough to keep postponing it, at least write code use examples. Those can be even more useful for programmers.
What can I add?
Jedi tricks are fine but should not be necessary as often as they are. By Jedi tricks I mean the “these are not the droids you are looking for one”, that is I am talking about having to pretend to be a program like a browser or a graphical user interface to access information and functionality that you need and have a right to. What’s wrong with being able to automate routine data retrieval tasks? Isn’t IT about that, mostly? Well, it’s not that the world is necessarily completely against scrapers and user interaction simulators, but that sometimes the world doesn’t want to put in the effort to design an API. Hope this changes with time. Programmers’ hours, energy and nerves will be saved. Also the machine and network resources.
APIs happen anyway. And if you let others’ just randomly pick at your code or look at your internals, how will you make changes later on? And improvements? Innovation? Think about it.
“You’re not done with your class if you haven’t tried to subclass it. Like forgetting leaky roof until rain. Raymond Hettinger at #EuroPython“
Subclassing is the ultimate API challenge. I mean, if you are designing your code for other’s to use, than consider subclassing issues as well.
“Hettinger on APIs – extendable but protected from damage. So modifying __setitem__ doesn’t change update. __local_setitem helps. #EuroPython“
If one changes the method that sets the item, will that automatically affect other functions that call upon it? Be careful about that. Hettinger explained it in detail. We could say that the Hettinger API talk offered some very concrete and interesting advice, watch the video if you are interested.
APIs are about writing code for other programmers to use (or your present and future self). I keep hoping it is easier to understand each other if one uses design patterns. I keep hoping that some day I’ll figure out and learn and use patterns. And do it well.
Ali Afshar‘s talk on Google API platform, which is really an infrastructure, was pretty fun. Hard to some up now. APIs for APIs. One API to rule them all. What more can I say?
Enough blogging for today. Some of the issues I mentioned here will be explained in future posts. See you in the next episode then!