This post originated from an RSS feed registered with Python Buzz
by Aaron Brady.
Original Post: Building a proper Python API
Feed Title: insom.me.uk
Feed URL: http://feeds2.feedburner.com/insommeuk
Feed Description: Posts related to using Python. Some tricks and tips, observations, hacks, and the Brand New Things.
I have now spent the last two hours reading up on Planet Python. I promised in a previous post (lots of P’s!) that I would try and rejoin the community, and reading other people’s output is obviously a big part of that.
In the time that it took me to catch up on 482 posts (one of which, about half-way, was my own previous post) 7 new ones came in. Active community!
As I’ve been working on an internal to iWeb project called “Parasite” for automating sysadmin tasks, I’ve gotten to write more Python code than usual, and it’s been done in the form of a proper library.
This is a bit of a first for me because for as long as I’ve been doing Python my code has fallen into two major camps: quick hack (one or two scripts) and web application (where the layout is defined by the framework I’m using, Quixote, web.py or even cgi).
Titus’s post is interesting because I’ve committed that sin in my own API; I make a call to a method which calls a method which calls a method which takes a bunch of optional arguments, and I use nested **kwargs to pull it off. Exactly as the man says, it’s both very difficult to test (typos are silently ignored) and very difficult for another developer to parse (ctags may be your friend).
Adam’s post interested me because he cites list comprehensions, and then map and filter. My immediate thought (and going through the comments, several other people’s thought) was that map and filter can be done quite happily with list (or generator) expressions.
I’m now finding in my code that I massively over-use list and generator expressions. I have to actively think “someone else will have to read this some day” and then go back and break nested expressions out into temporary variables or for loops.
They are the number one feature that I think I miss when programming in not-Python.
My final interesting experience in designing a library is that, although I know you need a init.py file to create a package, I still don’t truly know what’s appropriate to put in there. Do you import each library in there, so people don’t import libraries one by one? Or store global configuration variables (yes, not thread-safe, I know).
There doesn’t seem to be a lot of consensus based on the libraries I have installed either, so perhaps this is one of those “do what feels right” situations.