Python 3.0: what to do?

In recent months, many people considering taking up Python have asked me what Python beginners should do about the release of Python 3.0. Here's your answer.

nothing

To be more specific,
1. Install Python 2.6
2. (optional) Learn Python 3.0 syntax, and use it in Python 2.6.

It's been confusing, I admit; people hear about Python 3.0 and naturally wonder if Python 2.6 is now obsolete. No, Python 2.6 is specifically designed to make a smooth transition by accepting both Python 3.0 and 2.5 syntax.

The problem with installing Python 3.0 right away is that it will take a while before all the juicy third-party modules are available for 3.0. They should be available immediately for 2.6, though, since 2.6 can run them exactly as 2.5 does.

If you learn and use Python 3.0 syntax, then the code you're writing now in Python 2.6 will work in 3.0 in the future when your third-party modules are ready and you want to convert.

And if you'd rather ignore it all? That's fine, too. The differences are really pretty slight, and if you put off updating all your Python code for a year or two, it will be a very minor endeavor.

In short, it's really nothing to lose sleep over. And you absolutely don't need to hold off on learning Python until the situation is "more stable" - Python 2.6 provides you with a stable platform right now that bridges Python's past and future nicely.

Sprechen Sie GNU/Linux?

My boss has been supportive of my love for open-source, but I've never really been able to make him understand what makes it commercially viable. I think I finally blundered across the right analogy, though.

Simon and Schuster could develop a proprietary written language for their authors to write fiction in. Then, they could try to persuade people to learn Simon-and-Schusterese in order to read their books. In fact, if they did a fantastic job of marketing, they might persuade people to buy the right to learn Simon-and-Schusterese, then buy the books. Meanwhile, their legal department would chase down anybody using Simon-and-Schusterese without proper payment and licensing. Random House, HarperCollins, etc. could do the same with their own proprietary corporate languages. It's vastly more practical, though, for everybody to write in - and sell in - a language that nobody owns, everyone can use, and everyone contributes to.

Of course, in the real world, shared human languages came before publishing companies. But if, somehow, things had happened the other way around, you can see how there would be some initial skepticism (What? Give away our language for free? When we could charge money for it?), but companies that started working with a shared language would eventually dominate, and society would be much richer and more literate for it.

cmd2 0.4, now with testing

cmd2 0.4 has been released. Its biggest new feature is transcript-based testing. Basically, you can write a test suite for your cmd2-based application just this easily:

1. Add to your application script (suppose it's myCmd2App.py):

from cmd2 import Cmd2TestCase
class TestMyAppCase(Cmd2TestCase):
    CmdApp = CmdLineApp
    transcriptFileName = 'exampleSession.txt'

parser = optparse.OptionParser()
parser.add_option('-t', '--test', dest='unittests', action='store_true', default=False, help='Run unit test suite')
(callopts, callargs) = parser.parse_args()
if callopts.unittests:
    sys.argv = [sys.argv[0]]  # the --test argument upsets unittest.main()
    unittest.main()
else:
    app = CmdLineApp()
    app.cmdloop()

2. Run a session of your application. Run all the commands you want to test.

3. Cut-and-paste your entire session into exampleSession.txt.

4. Run python myCmd2App.py -t

Ta-da! cmd2 runs runs your app, issues all the commands saved in exampleSession.txt, and verifies that they produce the same output as in your transcript. Now you can change your app fearlessly without bugs sneaking in.

Finally, cmd2 is now available for Python 2.4 through 2.6.

Monty Python Fluxx

We are so going to play this game at PyCon.

Maybe I'll go to a talk or two, too. Between games.

sqlpython: getting crowded in here

I've come across two other SQL command-line clients lately, both written in Python:

pysql, like sqlpython, is for Oracle only.

sqlcmd is intended to work across all sorts of database backends (Oracle, postgreSQL, MySQL, etc.) seamlessly.

I intend to publicly review them soon. In the meantime, thought I'd let you know of their existence.

speaking at IEEE

In my ongoing campaign to teach Python to every multicellular organism in Ohio, I'm bringing my Smash, Crash, Kaboom Course in Python (you know, the one with the exploding planets) to this Tuesday's meeting of the IEEE-Dayton Section Computer Society Meeting. The chapter invites non-members to attend, too; no charge, but $3 to buy into the pizza.

The talk materials are here.

October 21, 2008 11:30 – 12:30pm
Introduction to Python

Lockheed Martin Corporate Sales

2940 Presidential Drive, Suite 290

Fairborn, OH, 45324 USA

Tags: python programming introduction class meeting

This hCalendar event brought to you by the hCalendar Creator.

Counting votes: You're doing it wrong

I have to admit, the first time I heard about people mistrusting computerized voting, I just felt amused. Silly Luddites, I thought. After all, how hard can it be for a computer to count?

Really hard, it turns out, if you start with the stupid premise that you ought to write every byte of the software from scratch, incorporating no preexisting software of known and verifiable quality. That's the approach that proprietary vending machine makers have taken - presumably to lend credibility to their patents.

There's a new interview with the Ohio Secretary of State, Jennifer Brunner, where she talks very frankly about the serious problems Ohio has found with its voting software. I'm glad Ohio now offers a paper ballot option. I'm going to use it. I truly have no idea what happened to my 2004 vote.

There's a perfect solution waiting to be used: PVote by Ka-Ping Yee, one of the Python community's greats. In his interview with NPR's Science Friday, he describes how voting software should and can be written: as a minimal, readable, high-level program that relies on existing open-source components of thoroughly-verified quality. Ka-Ping, my vote is for you.

PyOhio's table at Ohio LinuxFest

This year, PyOhio decided to buy table space in the nonprofit exhibitors' area of Ohio LinuxFest to publicize PyOhio (as well as PyCon and Python in general).

It was a really good decision! The "hallway track" is one of the most interesting parts of any conference, of course, but when you have a table of interesting stuff to draw people in and start conversations about, it goes to the next level. I barely made it into any formally scheduled events at all, and had lots of fun meeting people from the big and growing open-source community. I tried to preserve my voice, but I was half-hoarse by the time my 4:00 talk started.

• Ponyshow was a big hit - it caught peoples' eye and drew them over to the table. I'd still like to add more flashy graphics to it for next year, though - I ran short on time, and had trouble installing pyglet. Tables in the nonprofit zone lacked electricity, but I used two laptops to get around that - one on display at the table and one recharging at an outlet elsewhere.
• Python stickers donated by PyCon were an even bigger hit. If 1/2 the people who took a sticker are using or will use Python, we've got a very healthy community here!
• I whipped up a homemade PyOhio banner that went pretty well. I projected our logo onto a wall, traced the outline, used an Exacto knife to make a stencil from the pattern, then used some fabric spray paint.
• For next year: bring candy. We may see if we can do a swag raffle of our own, too.
• A rerun of last year's Python introduction went well. The Python Beginners' Hackathon was good, but small. We'll have to think about what might need changes there.
• I really like the idea of PyOhio running something on the Friday of next year's LinuxFest. Join the pyohio-organizers mailing list to help kick around ideas for that.

There was a lot of interest among the attendees. There were more people already actively using Python than I expected, and virtually everyone else knew Python as something they wanted to learn more about. I think we'll see that reflected in an even bigger and more intense PyOhio next year.

Ohio LinuxFest 2008 - talk materials

Thanks to my Ohio LinuxFest audience for learning some Python with me! The talk materials are here.

Here's the "Resources for Python Learners" handout.

I had a great time at OLF, particularly in the "hallway track"; we have a really fun and growing open-source community in Ohio. Go, us!

I can plot that data in two keystrokes

(plus a carriage return)

One of the ideas I most gleefully stole from YASQL for sqlpython is special terminators, sequences like \g and \c that replace a SELECT statement's ending semicolon. When a query ends with a special terminator, the output is specially formatted: \c gives CSV, \h gives HTML, \t gives transposed (columns as rows / rows as columns), etc. Type help terminators for details.

sqlpython 1.5.0 is out today, with the most demented special output format yet: CHARTS! Instant ad-hoc grapical goodness direct from your query, no tedious mucking around in spreadsheets or exporting to another program. Just terminate your query with \l (line graph), \L (scatter graph - no lines), \p (pie chart), or \b (bar graph).





Also, as of 1.5.0, it's pretty easy to define your own special terminators and formats. Just install sqlpython in uncompressed form (easy_install -UZ will do that), open up output_templates.py, and follow the pattern.

ponyshow: showing off in Python

PyOhio is getting a table at Ohio LinuxFest to advertise PyOhio and Python in general. We're going to set up a computer running demonstrations of eye-catching Python tricks - stuff passing geeks can look at and think, "Hunh! That's pretty cool! I'm going to try this Python thing."

To run the demo, I've written a little script called ponyshow. You can use it yourself (on *nix) - install Mercurial, then
hg clone http://hg.assembla.com/ponyshow ponyshow

I need suggestions for what to put in the show! If you had a few lines of code to show why you love Python, what would they be? Importing modules is fine - I'm certainly going to show off vPython and pyglet, for example. What would you show?

more area events

Ohio LinuxFest isn't the only major geeky event coming up in our area. Also check out:

• the Miami Valley Joint Societies meeting: more geeky groups than you can shake a USB drive at, all coming together for their annual dinner meeting. Sep. 25 in Dayton.
• .NET University: a free 101-level education in .NET. Nov. 8 in Columbus.
• 50 Years of Computing at UC: the big picture. Nov. 10-11 in Cincinnati.

Geek Event Finder: now working

It's working! The Geek Event Finder on Google App Engine! Go play!

In some ways, the Google App Engine is a dream. Not thinking about the app server is wonderful. Deploying couldn't be easier.

I hate the GAE datastore with the passion of a thousand blazing suns, however. 90% of the work of this project has been trying to figure out workarounds and kludges for its bizzare limitations, like

• There is no mass delete. None. No truncate. No way to get rid of a large number of records at once.
• Bulk upload exists, but it always appends to the datastore - never replaces - which brings you right back to the "no mass delete" problem.
• No long-running operations - anything that would take more than a couple seconds dies - so you can't loop over all your records to do something (like delete them).
• Countless unexpected restrictions on queries. Can't filter on one property while sorting on another. Can't do inequality filters on more than one property. Can't filter on a string property if it is multiline (has \n's) or is longer than 500 characters (type Text). Can't use any function calls or arithmetic within a WHERE clause. Queries that fetch a large number of records die instead of completing (so I fetch in LIMIT 20 batches and assemble the results on the app side... crazy).

So if you look at the code and see some incredibly stupid stuff going on with data access - trust me, I tried fifteen different sane ways first. I am so not buying the buzz about this being "the future of databases". Fighting for hours to try to kludge your way to your data... that's the Bad Old Days, not the future.

My workaround for mass deletion was to write pages that would delete one record, then invoke it in a loop from my client computer. That has to run all night to clean out the datastore when new data is uploaded.

But anyway. I'm still very happy. It works!

Ohio LinuxFest

Ohio LinuxFest is Oct. 11 - one month from today!

It's free, it's fabulous. Missing it would be like missing your own birthday. Go get registered!


The PyOhio gang is going cook up some good stuff to do - a table in the midway, a Python workshop in the Open Spaces, etc. Let me know if you have ideas and/or if you'd like to help staff the table.

BigTable blues

This was supposed to be the blog entry where I would announce the Geek Event Aggregator's successful port to Google App Engine.

(sigh)

I've read an awful lot of buzz about how GAE's BigTable is the Next Big Thing in data, makes RDBMS obsolete, etc. Maybe I'm just doing it wrong, but right now I am utterly unimpressed.

The Geek Event Aggregator needs to search its database of 5000 or so events for events whose longitude and latitude are close enough to the user to be of interest. Does that sound so impossible?

I couldn't do it in GAE. First, "Inequality Filters Are Allowed On One Property Only" - so I can filter for longitude or latitude, but not both. I had to filter only for longitude, pull all resulting records into the application, and finish boiling the ocean in my app. It was slow, in the local application environment, but I hoped it would run faster once uploaded to the actual GAE production servers.

In production, though, it doesn't run at all - "Timeout: datastore timeout: operation took too long.". Querying from 5000 records - too much for the mighty BigTable, apparently. Dropping the filters on longitude (to do all the filtering in the app, in case inequality filtering is just so poisonous) didn't help, either.

Oh well. I still enjoyed working with GAE at first, and maybe I'll use it again for something with very light data demands. For the Geek Event Aggregator, I do have a server available where I can host in TurboGears - it'll just take a bit of rewriting. Later this week, hopefully.

recursive dowload with wget

I often need to download documentation for offline use. Online docs typically come as a finely branched tree of separate .html files; sometimes a one-page or PDF version is also available, but those aren't as convenient to use.

I'd gotten sick of using "File/Save As..." from my browser again and again, but Firefox shortcuts like DownThemAll flattened the directory structure, broke the internal links, and didn't crawl them to get sub-pages.

The answer, of course, was in my /usr/bin all along: wget.

catherine@Elli:~/docs$ wget --recursive --convert-links \
> --page-requisites --no-parent \
> http://www.postgresql.org/docs/8.3/interactive/index.html

or, shortcut form,

catherine@Elli:~/docs$ wget -rkp -np \
> http://www.postgresql.org/docs/8.3/interactive/index.html

pulls down the everything beneath the index page, and it turns out perfectly, with a single command!

--convert-links adjusts all the internal hyperlinks so they'll work perfectly in your downloaded version.

Without --no-parent, wget would find the link to "Home" and download everything under that.

--page-requisites makes sure you get the images, stylesheets, etc. for your pages to work properly.

Now bookmark the downloaded top page in firefox, give the bookmark a keyword, and voila! Now just typing your keyword into the Firefox URL bar gets you to your perfect offline mirror.

Regex skirt review

I got my xkcd regex skirt as a birthday present (funny what subtle hints like "this is exactly what I want for my birthday please please please" will do), so I thought I'd give a review. An hReview-microformatted review, of course.

gloriously geeky, if flawed

Aug 22, 2008 by
Catherine Devlin
(sam18xgy4fz@liquidid.net)product

XKCD Regex Cheat Skirt

Rating: 4 of 5

We've all got a drawer full of geeky T-shirts. But what about a geeky skirt? Thanks to XKCD, it finally exists!

The text is regular expressions syntax reminders, oriented upside down so you can read it while you sit. Simple stuff, like:

Must escape: \|()[{^$*+? 
^ start of string 
$ end of string 
[^abc] ^ means not 
\n Newline 
{N,M} N to M

The font is large, comfortable to read while sitting. I wish the lines weren't double-spaced - I think 1.5 spacing would make the text look more like a trendy decorative hem accent.

The sizes run big. I wear 10's or 12's, ordered the medium, and it is more than big enough, even without the stretchiness. It's a soft, stretchy fabric, stretchy enough to do Rockettes high-kicks if that's what you do (but programming pays better).

The hem falls a bit above the knee, but not at all "you are not leaving the house like that young lady" high.

I'm a little disappointed in the craftsmanship, to tell the truth, for the $35. It kind of looks like a skirt made by T-shirt makers - it's two simple trapezoidal panels sewn together. The text leaves a fairly broad gap at each edge of the panels, making it really obvious where the side seams are. (I guess that could be considered a fashion choice, but I prefer hiding the seams.) The print is that slightly raised plasticky print, and I have zero confidence in its longevity. I will obviously not only have to launder it gently as advised, but also refrain from wearing it every single day. Save it for geeky occasions where it will be properly appreciated.

Nonetheless, it is far and away my favorite skirt, because it is far and away the winner of the "geekiest skirt ever" contest, and that trumps everything in my book.

0.3

This hReview brought to you by the hReview Creator.

taking FOSS to the people

It's all very well to invite newbies to come to your Linux group, but you're not going to get really new people that way. Coming to a meeting or an Installfest is a commitment that demands strong, specific curiosity at the very least. Chances are, if someone knows enough about Linux to know that they want to know Linux, they're going to learn it, helpful usergroup or not. That's especially true now that the entry barrier is so low with super-easy distributions like Ubuntu. But what about those who don't know what they're missing?

That's why some of us from Dayton Linux User Group are considering renting a booth at the Montgomery County Fair. We can set up several computers and let people touch, try, and see just how easy it is - people who had never even heard of Linux or open-source, people who had no idea there was a choice, who thought that Microsoft was just how computers run. Step right up, folks. Surf a webpage, write a document, edit a spreadsheet. It's real, and it doesn't bite.

"Do you know that Tux loves you, and has a wonderful plan for your computer?"

(WOW, if only I had cartooning talent, I would make THE BEST mockup of a lowbrow evangelical tract there has ever been.)

(Wait a minute. Since when did that require cartooning talent?)

(Incidentally, I really am a hardcore Christian. Seriously. Maybe that's why this sort of thing appeals to me so much. "Freely you have received, freely give"; Jesus wrote the GPL!)

The only thing that may stop us is the booth fee: $270. It's reasonable, all things considered, but it's still a sizable hat to pass around for a small group.

Anyway, whether we get this together in time for the fair or not, I'd love to get other ideas for where to take a show like this. The fair is perfect because it has a whole lot of people milling around looking for something interesting. Where else?

Good Kids and Open Spaces

Not everything at PyOhio was perfect, of course. In particular, we were frustrated that we didn't get more participation in the Open Spaces. Some of the attendees pretty much took a spot in the auditorium, watched the scheduled talks, and went home. I think they were satisfied, but those attendees missed out on a lot.

I wasn't too surprised, since even PyCon wrestles with how to encourage Open Space participation. Many PyOhio attendees were inexperienced conference-goers with absolutely no experience with Open Spaces. But I don't think unfamiliarity was the only barrier.

Back in high school, I was one of the Good Kids. I was Born to be Mild. I went to class early, sat down, readied my notebooks, and waited for the teacher to start. I did not hang around in the hallway gossiping. I certainly did not cut class!

I think most people who become programmers started out as Good Kids, and that's part of why this is hard. We can put a preachy message in the program guide singing the virtues of Open Spaces and the hallway track, of informal, collaborative learning - but they were Good Kids, and they're not buying it. When we say, "get into unplanned discussions, skip some scheduled talks in favor of Open Spaces", it sounds to them like "cut class and hang out." No wonder it's a tough sell! Closing their ears to that is exactly how they became educated enough to be at a programming conference in the first place. In high school, the things your peers could teach you would probably get you arrested, hospitalized, and/or pregnant.

So we've got some ideas to get people over this psychological hump for PyOhio 2009. We're going to use panel discussions to ease people from listening into talking, try a schedule that forces people to get up and move around and bump into each other, and leave time slots where there are no scheduled talks.

Honest, everybody, it's OK. One Good Kid to another.

[EDIT: Let me make clear that this wasn't the only thing keeping people in their seats. We had a jam-packed schedule - gave in to the "fit everything in" temptation, I'm afraid; the Open Space rooms were distant from the main lecture room; and there was no natural transition to a hanging-out space when the library closed at 6. We'll certainly be looking hard for ways to improve those for PyOhio 2009.]

PyOhio: wow

Wow. PyOhio went great. I have so much to say, I hardly know where to start. Expect multiple posts.

The hope was to duplicate some of the learning and atmosphere of PyCon on the small scale. I really think we achieved it. The talks were excellent, attendee enthusiasm was high, and plenty of people stepped up to the tasks that needed doing.

THANK YOU to everybody who was involved!

Not everything was perfect, of course. I'll devote a full post to glitches and mistakes. But in general, I'm extremely happy. We could have sat around wondering whether this area could really support a good regional conference, but instead, we just went ahead and did the experiment, and the answer is clear: yes, it can and it did!

Check out some of the neat swag donation we got from WearPython and Apress!