Pittsburgh Python: night of the favorite module
How I benefited in the past
For example, one of these “favorite module night” sessions was where I learned about Kenneth Reitz’s
requests library. Very often it is easy to not be aware of the rapidly changing ecology of very useful libraries in a programming language ecosystem outside of the official “standard library”, especially when using a language that is not one’s primary working language. For example, Python has never been one of my primary working languages, so I’m not as up to date on what all the best tools are to use. But just a couple of weeks ago, I had to do some work with Python, and
requests came in very handy.
Josh Adelman opened the show-and-tell with a demo of IPython Notebook. This is a truly fantastic interactive environment for developing code while creating a full document for publication and sharing. He uses it not only for research but also for his students to use in his teaching.
If you’ve used Mathematica, the concept is similar to that environment.
I’m also excited that IPython Notebook has been the direct inspiration for similar projects for other languages, e.g., Scala Notebook for Scala in development.
Josh gave a link to this cool blog that uses IPython Notebook.
Nick Sloan presented on Sentry, a service for collecting errors in your program and notifying you of them, and Raven, the official Python client for Sentry. Sentry is actually open source, so you could host it yourself, but paying for the hosted service provides conveniences.
Using Sentry is no more than using ordinary Python logging after calling a setup function. The ease of use made it sound like a winner.
Joe Esposito presented on
docopt, a library for command line parsing. The interesting thing about it is that it implements an external domain-specific language for describing command lines: you write a usage message, as a string, and
docopt parses it in order to deduce what the expectations and constraints are. This is a very ambitious approach, contrary to the usual internal API-based approaches, some of which are sophisticated and implement an internal domain-specific language.
Of course, Joe contrasted this library with one of the standard command line parsing libraries for Python,
argparse, which is lower-level so that when you use it, the high-level end user usage is not as immediately readable.
There were a lot of good questions about
docopt since it seemed magical. I’ve decided to write more about all this in a separate blog post about command line parsers.
I gave a short 5-minute presentation on
hypothesis, a library in development for doing property-based testing, inspired by QuickCheck and ScalaCheck. As I have done recently when giving a much longer talk on property-based testing using ScalaCheck, I focused on motivating the use of property-based testing as an addition to example-based testing.
Materials for my lightning talk are here, and my few slides are below:
Tim Lesher talked about
itertools, a very useful part of the standard library that provides support for efficient functional programming idioms. Part of the efficiency comes from the use of iterators in order to avoid constructing intermediate lists; this is a way of simulating the lazy sequences that are standard in languages such as ML, Haskell, Scala, and Clojure.
Tim noted that although
itertools is powerful, “don’t be stupid”: don’t write obscure-looking code with it just because you can.
Josh noted that the documentation for
itertools is great, with recipes that show you not only how to do things, and also with code for the equivalent more complicated code that you would have to write if you didn’t use
itertools. I agree that the documentation for
itertools is a model of high-quality documentation for a library. Check it out, and use it!
Craig gave a little presentation on
argparse, the aforementioned standard library for command line parsing. He noted it was ironic that he had prepared to speak on it before Joe independently decided to talk about
docopt. (Actually, I like
argparse and had considered talking about it before Craig submitted it already.)
One feature he uses from
argparse is the ability to create mutually exclusive groups. There was a question of whether this is supported in
As mentioned earlier, I’ll write more about both
docopt in a separate blog post.
Someone shared not a “favorite module”, but a favorite book, “The Python Standard Library by Example”. I’m happy he did, because it is in fact an excellent reference for anyone using the Python standard library, with concrete examples that you can take and use. Too often, I have found that standard documentation is too terse.
The book is based on “Python Module of the Week”, which is a great online resource.
Introductions for new people
An important part of the vibe of the Pittsburgh Python User Group is how it tries to get everyone actively involved in the local Python community.
There is a tradition of periodically having everyone introduce themselves, to counter the tendency sometimes in these kinds of groups for people to attend a meeting out of curiosity and then silently leave and perhaps not come back, out of intimidation or not knowing how to benefit or contribute. I know I have done that before, especially when attending the meeting of a group where I didn’t really know anybody ahead of time and still knew very little about the topics discussed by the group (such as when I joined the Pittsburgh Ruby group as one who had barely used any Ruby).
Since so many people showed up, and a lot seemed to be new faces, we had a round of introductions. I hope we’ll continue to see some of these new faces in the future!
Thanks again to Google Pittsburgh for hosting the Pittsburgh Python User Group meeting, and Steve Gross of Google for being the guy who makes it able for us to meet there!comments powered by Disqus