I recently finished up Problem 17, and since the problem was fairly straightforward, I used it as an opportunity to explore some of Python’s language features that I’ve been meaning to look into.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 |
|
Generator Expressions
The quick version: They’re like list comprehensions, only lazy. The longer version resides in PEP 289. The verdict: They rock. It didn’t make a big difference in this problem, but in general, it’s nice that you don’t have to allocate enough memory to contain an entire list. One problem with them is that once you’ve consumed an element of the generator expression, you can’t get it back, so they aren’t well-suited for problems where you need to iterate across the data more than once.
Regexes
Regexes are hardly unique to Python, but this is the first time I’ve ever used them in Python. One feature I was excited to try—and that Python pioneered—is named capturing groups but the regex I used in this example didn’t need them.
Docstrings
I’ve written docstrings before, but this is the first time I’ve tried
to generate stand-alone documentation from them. To do the generation,
I used epydoc. The original PEP 257 defines
docstrings in terms of plaintext, but PEP 287 establishes
reStructuredText as a richer alternative. Since I was
generating documentation from the docstrings, I decided to go with
reStructuredText. To avoid typing --docformat restructuredtext
every
time I invoked epydoc
again:
1
|
|
While it took a while to get used to it (I’ve gotten pretty set in my Markdown ways), I really like it so far. In fact, I liked it enough to write this entire blog post in it and simply post the generated HTML into Blogger.
Back to flipping out…