Lonely Lion

Just a quick response to this write up on the lack of growth in Python 3000. Python 3000 really isn’t the giant sea change that I thought it was going to be. Most of the significant work is under the covers, optimizations that will benefit me without me necessarily knowing it. The author of the above post (I’m sorry, I couldn’t find the author’s name), like me, is a fan of Ruby and Python. I think he wants Python 3000 to take on some of the traits we both love about Ruby (extreme flexibility, cleverness, many ways to do it). I know where he’s coming from, but that wouldn’t be very ‘Pythonic,’ it would be ‘Rubyonic.’

One of my favorite bits about being a polyglot is the differences between languages. What’s the point of making Python like Ruby? What’s the point of making Perl like Python? If everyone is sort of doing the same thing, where’s the fun in learning new stuff? I love Python, I love Ruby, I even love Perl. Let’s preserve their differences. Python doesn’t want you to muck around with the syntax, Ruby does. Use Ruby when appropriate, use Python when appropriate. Right?

Speaking of polyglotism, I bought that Prag-Prog Errrrrlang book over the weekend. All variables are constant, and must start with a capital letter. How’s that for balls nuts? Woo hoo! Viva la Different!

I’m almost a month late, but I just realized that fixtures have been added to the Django testing docs. They’re pretty slick looking. Also, just below the fixtures section is a good write up on using frameworks other than unittest and doctest to test your apps. Hurray for new documentation!

Dave Thomas posted a better explanation of the goals behind some recent Rails REST stuff today. So, the goal is to write REST first, and have your web face be a proxy for REST, just like a thick client would be. I’ve never thought of REST like that, it’s usually a nice little add-on at the end of a web app. It’s an interesting idea, for sure. I get the concept, it seems all well and good, I’m just not sure I understand what it really buys you. What’s the difference between building a conventional web app first, then adding a REST service on top of it? The suggestion is really just to swap the order out, right? Build your REST service, then your web app consumes your REST service? I get the concept (I think), I’m just not entirely sure why that’s a step forward. It’s definitely a step, I’m just not sure in which direction. My gut says it’s to the side.

This is clearly the start of a conceptual waltz.

Found this write up about Romania rejecting the OLPC via Grig’s blog. The Romanian parliament rejected an OLPC proposal because the XO “lacks MS Word.” Clearly they don’t understand the project, which is a shame. I worked for the Chicago Public School system for a few months. I know that education isn’t safe from the influence of large technology companies. I’m assuming these companies are responsible for propagating these kinds of anti-OLPC arguments. The OLPC project isn’t about laptops, it’s about education. Unfortunately, in the eyes of many of these technology companies, it is about laptops. That story is very disappointing.

James Bennett on the issues with redistributing Django apps. It’s a tough problem. I did a bunch of hackish stuff to get the mediocre blog software to be sort of distributable, but it’s ugly. I’ll be interested to see what comes next.

I finished the 20th and final (apart from the unfinished 21st novel) book in the Aubrey Maturin series this morning on the train. It’s kind of neat timing, as today is my last day working at my current job. New job won’t require me to ride the CTA. These boat books were big CTA reading for me over the past couple of years, so the wrap up is tremendously appropriate.

I’m not recommending the books to anyone, because they’re really not for everyone. I loved them, more than any other series of books I’ve ever read. I feel like I should get some sort of lapel pin to mark the occasion. Something.

A while ago I read an article on prediction markets, and ended up getting hooked on the Hollywood Stock Exchange. HSX is interesting to me for a couple of reasons. First it’s a predictive market for something I like and have opinions about (movies). Second, it’s a predictive market with a concrete pricing structure. Movie stocks are priced based on how much the movie will make in the first four weeks of release. If a movie makes $70 million in the first four weeks, it will de-list at $70 / share. Some predictive markets (like the O’Reilly Buzz Game) have vague pricing models that don’t necessarily have a definite outcome.

It’s a little bit nerdy, but I enjoy it. I check on my stocks every couple of days. I recently took a bath shorting Ghost Rider, but managed to make it back with a heavy investment off of news that the director of 300 signed on to do Watchmen.

So, seriously…it’s nerdy. However, I took the nerdiness to geeky extremes (nerds consume, geeks create) and found an XML feed of all the HSX stocks. I wrote a parser script in the lobby at Pycon that dumps the data into MySQL. Last night, in about an hour or so, I built out a series of RSS feeds for each stock. The feeds are pretty simplistic, and will most likely change at some point, but it’s a good start. The feeds can be found at hsx.lonelylion.com. I’m also storing away the data over time. I’m not sure what I’d like to do with it, but it’s fun to have. Also, this is a Django Joint.

There’s a draft of a PEP floating around the Python-3000 list about reforming the way metaclasses are formed. Although I’m not a meta-class programmer by any means, I have read up on them, and appreciate their usefulness in frameworks like Django and SQLObject.

I’ve always thought the syntax wasn’t very pretty __metaclass__ just looking kind of funky.

I guess I’m not alone…from the unfinished PEP:

    The other, weaker, rationale is purely cosmetic: The current method
    for specifying a metaclass is by assignment to the special variable
    __metaclass__, which is considered by some to be aesthetically less
    than ideal. Others disagree strongly with that opinion. This PEP
    will not address this issue, other than to note it, since aesthetic
    debates cannot be resolved via logical proofs.

Specification

    In the new model, the syntax for specifying a metaclass is via a
    keyword argument in the list of base classes:

      class Foo(base1, base2, metaclass=mymeta):

Personally, I like that syntax. It feels less magical, and more like “hey, FYI, the metaclass that’s producing this object is ‘mymeta’.”

I admit to not understanding the usefulness of a bunch of other stuff addressed in the PEP, but that bit I think is good. Metaclasses are a difficult to approach, it feels like you’re hacking something. A gentler syntax makes it seem more reasonable and accepted, less like you’re doing something you shouldn’t.

EDITED TO ADD: the PEP was assigned a number further down the email chain: PEP 3115.

I just saw this ant simulator on reddit, very cool looking. It’s almost exactly what I was shooting for when I started messing around with my various bee simulators. I never buckled down and finished any of them. The bees have lost to the ants. Sorry bees.

I’ve been adding code here and there to the fabulously non-featured tastebud-project, and have been debating whether or not to include comments as a feature. This morning, the Freakonomics guy posted this bit about “who comments?” It reminded me that I need to make a decision about comments.

tastebud-project, bless its little heart, is not really a full featured blogging package, it’s just a Django app that I kept reusing and decided to formalize a bit and release. The two projects that led to it (Tastebud and Victim of Time) don’t allow comments, simply because the people running both sites (Camri and I for Tastebud and Brett and Todd for VoT) don’t want to manage a bunch of comments. My previous side-project as message board maker for Chicago improvisers made me really dislike managing communities. A recent post by the CherryPy guy sums it up nicely, “You’re writing a community tool with a moderator mode. Do you really want to be a bouncer for the rest of your life?”

I allow comments on this blog, which is clearly a huge deal, as I get hundreds and hundreds of comments (I don’t, I’m being sarcastic). I had them turned off for a very long time, and never really felt bad about it. Comments, in general, are a nice way to build a community, but really…the side projects I like to work on aren’t typically “community” projects, they’re more like publishing projects. I want to write something, for you. I’m not necessarily trying to start a dialogue. Does that sound dickish? It’s not meant to be. I know it sounds very Web 1.0-ish, but…hey…it’s the truth. You can’t argue with the truth! Right? Uh…right?

So, in short, as of right this minute, I’m not going to include comments on the awesome tastebud-project. This decision is subject to change at a moments notice. The good thing is, if you actually use tastebud-project (why the hell would you do that?), it’s easy enough to add comments, as Django bakes them right in. So…comment away suckers.