about MattCode coverage gets a bad rap. People say it's meaningless. In my "Managing Complexity" talk at PyCon 2008, I made the analogy that code coverage was like a shield. One is exposed where the shield doesn't cover. But just because you have shield doesn't mean that your shield is any good. You could be battling against a fire breathing dragon with a WOODEN shield (smart one Wiglaf). Your exposed areas could be dead code (which the literature says is more likely to cause bugs) or code that is hard to test.
This last point, code that is hard to test was hit home to me over the weekend when I spent some time going over Miško Hevery's blog about testability. While perusing the site and some of his presos, it hit me that 100% code coverage (and I'm talking about the line/statement variety here) indicates something else. That your code is testable. If you can't get 100% coverage, then you are probably violating some of the 10 things that make code hard to test. I especially appreciate the Law of Demeter analogy he uses, (paraphrasing) "You don't give the cashier your wallet when they tell your lunch costs $5.98. You give them the money (or the credit card)". So if you are struggling getting the coverage numbers you want, you probably need to use dependency injection to get rid of that Law of Demeter violation....
Of course, now that Python has branch coverage. we can get to work on some of the interesting things that you get from path coverage. Oh yeah, editor support would be nice too.
Why does firefox (yeah, it has Firebug so I develop against it) silently ignore errors? Everytime I think I might like some of Javascript, I'm reminded that I hate the runtime environment (development is slightly less painful with js2-mode and strict use of jslint). Sure it's a scripting language so it doesn't fail as early as some other languages, but please tell me about the error rather than just siliently doing nothing....
Here's an example, that both firefox and chromium (chromium->developer tools->scripts actually tells me whats wrong!) silently ignore (jslint and js2-mode as well). Python would at least tell me what an idiot I am (or a line number nearby):
<html> <script> var frobnicate = function () { var sb, content; sb[sb.length] = "foo"; sb[sb.length] = "bar"; content = sb.join(''); document.getElementById('FOO').innerHTML = content; }; </script> <body onload="frobnicate()"> <div id="FOO"></div> </body> </html></End Rant>
I would be remiss if I didn't thank my grandfather, Paul Huber, for his courage and bravery as he served his country during WWII. He's being honored today at the U. For almost 5 years he served his country in Algiers, Sicily, Utah Beach (D-Day), France and Germany. A short bio is here, from one of the "Greatest Generation".
I'm a visual person. A nice chart or graph somehow fits my brain better than lots of text. Here's an image I wish I had when I first installed awesome. I wish I had it a few weeks back when asked about tiling window managers at UTOSC. Now I'm thinking about giving the latest version of xmonad a try (maybe I'll make an xmonad version). (And if I had more time, I'd hack on the Python tiling wm, qtile).

This covers the default configuration for awesome. And really that's about all you need to know. Once you know how to start a terminal, and kill clients, the other basic commands are for navigation and changing layout/float/maximize.
So if you've been thinking about trying tiling wm's, give the recent awesome 3.4 a try. Your hands and wrists might thank you.
Chris McDonough clearly explains what code is appropriate at the module level. In the spirit of "importing code shouldn't have weird side effects", here's his list:
And then this great quote: Any other sort of logic inside the top level execution path of a Python module (any code that would be executed during "import") should be regarded with great suspicion and perhaps even loathing.
Here here Chris! Perhaps you should start a Foundation, Crusaders against Suspicious (Python) code.
(I guess this is sort of a retweet, since I didn't want to login to comment)
I had a good time at UTOS. The first day was mostly spent in my Intermediate Python workshop. For those who attended I apologize for not having a break! 2.5 hours is a long time to listen to me spout off. I think the workshop went well though. We discussed testing (unittest/doctest), functional programming, functions, decorators, iterations, list comprehensions and generators. After the speaking was the hands on portion. The room was packed for the first part (some people stood for most of the time). For the next hour or so people stayed around and hacked on python. It was really cool to see people who had "only written 3 python programs", write a generator and understand what is happening.
That night we had a Utah Python group meeting. Stephen McQuay did a great job of introducing Python. One interesting fact, is that he said the main impetus for him learning python was the "import antigravity" xkcd cartoon. I've never heard that one before!
I also talked about coverage and that went well. I had a little technical glitch at the start as OOo seemed to have problems with the projector. (I've never seen it before but my presentation would open just fine when the projector was not plugged but would hang when it was. Very weird and frustrating. I finally opened OOo and then connected the projector and it worked. For my workshop I made pdf backups of my preso in case this happened, but didn't bother for this since I had no problem the with the workshop preso. Live and learn. Always make a pdf backup on a thumbdrive!)
The other sessions I attended were pretty good. One note, when you are demoing on a console there are two problems. One is font size. The other is that terminals show the input at the bottom of the screen (unless you are ctrl-l'ing all day long), which can be hard to see unless the screen is pretty high. A tool like pykeyview can go a long way towards helping with the latter problem (which came up in 2 sessions I attended).
My brother has a pretty cool iphone game in the works. If anyone is interested in beta testing and providing feedback, please get in touch with him!
Tomorrow I'm giving a workshop on Intermediate Python at the UTOS. In the session I'll discuss testing with the unittest and doctest modules for Python. Then I discuss a bunch of what I consider to be intermediate Python constructs. Included are decorators, list comprehensions, generators, generator expressions, functional constructs and function arguments. Included when possible are explanations of why stuff works (such as generators and decorators) rather than just throwing out examples. Hopefully the theory helps with understanding how to apply this knowledge later.

One might wonder why I'm bundling testing in with the talk? I guess it's excusable for beginners to neglect testing ;)
I created two handouts (generated with rst2odt) for the workshop, one on testing and another on the intermediate stuff. I've also generated my slides (via rst2odp of course). A tarball containing said materials is here.
Are people interested in handouts/cheatsheets? Should I throw the source up to github if anyone wants to collaborate?

