Spyced

I presented on PyGame at the utah python user group last night. (When I don't get someone else lined up to speak in advance, I end up doing it myself. You'd think that would be enough motivation to not procrastinate.) I had a lot of fun preparing this. I'd never used PyGame before, but as a teenager I spent a lot of time in the same space. (Anyone remember YakIcons?) So the general concepts were familiar to me, and I was pleasantly surprised by how good a job PyGame did at making things easy for me. Here are my pygame slides , and my pyquest game skeleton is here . (PyQuest is of course inspired by Crystal Quest -- the mac game, not the XB 360 remake -- and the graphics and sound files are from Solar Wolf, which I guess makes PyQuest LGPL. This caused Paul Cannon some serious mental trauma at the meeting, seeing and hearing solar-wolf-and-yet-not-solar-wolf.)

[Update Oct 2006: here is another serving of SqlSoup . Update 2: SqlSoup documentation is now part of the SQLAlchemy wiki.] Ian Bicking wrote in Towards PHP that a successful Python PHP-killer (as Spyce aspires to be) will need to include a simple data-access tool that Just Works. I had two thoughts: He's absolutely right I could do this with SqlAlchemy in an afternoon My afternoons are in short supply these days, and it took two of them, counting the documentation. But it's live now, as sqlalchemy.ext.sqlsoup. (The 0.1.5 release includes a docless version of sqlsoup; I recommend the subversion code until Mike rolls a new official release.) SqlSoup is NOT an ORM per se, although naturally it plays nicely with SqlAlchemy. SqlSoup inspects your database and reflects its contents with no other work required; in particular, no model definitions are necessary. Here's what SqlSoup looks like, given pyweboff-ish tables of users, books, and loans (SQL to set up t...

I spent some time yesterday researching (free) database replication options. Judging from the newsgroup posts I saw, there's a lot of confusion out there. The most common use case appears to be failover, i.e., you want to minimize downtime in the face of software or hardware failure by replicating your data across multiple machines. But, the most commonly-used options are completely inappropriate for this purpose. As Josh Berkus explained, there are two "dimensions" to replication : synchronous vs async, and master/slave vs multimaster. For a failover solution, if you want database B to take over from database A in case of failure, with no data loss, only synchronous solutions make sense . By definition, asynchronous replication means that database A can commit a transaction before those changes are also committed to database B. If A happens to fail between commit and replication, you've lost data. If that's not acceptable for you, then neither is async ...

For our March meeting, the Utah python user group had multiple people present a solution to the PyWebOff challenge . This is not an attempt at an authoritative web frameworks review. The backgrounds of the presenters are too different -- in particular, only the Rails and Spyce presenters had prior prior experience with the frameworks they used. That said -- and obviously I'm all sorts of biased as both presenter and maintainer of Spyce -- I think Spyce came off looking pretty well. Partly because it was designed to automate repetitive tasks with relatively little "magic," and partly because Spyce doesn't try to put you in a straitjacket: you can write strict MVC code if you want, but if mixing some code into your view makes more sense than the alternatives, you can do that too. "I," "me," etc. in the remainder of this post refers to the presenter speaking of himself. In presentation order, here are my notes: TurboGears Presenter: Byron C...

Mike Orr's pycon 2006 writeup is out in the March Linux Gazette . The usual suspects are present (keynote summaries, etc) as well as some lightning talk info that I haven't seen blogged elsewhere. (I loved Chad Whitacre's Testosterone screencast: "The Manly Python Testing Interface.")

I presented an IDE review at PyCon last Friday. It was basically a re-review of what I thought were the 3 most promising IDEs from the Utah Python User Group IDE review , to which I added SPE, which was by far the most popular of the ones we left out that time. The versions reviewed are: PyDev 1.0.2 SPE 0.8.2.a Komodo 3.5.2 Wing IDE 2.1 beta 1 I'd intended to base my presentation around a comparison of writing a smallish program in each of the IDEs, but the more I tried to make this not suck, the more I realized it was a losing proposition. Instead, I decided to try to focus on the features in each that most set them apart from the others (both positive and negative); this seemed more likely be useful. (I did a new feature matrix for this review, which is included after my comments. The slides I used are also up, at http://utahpython.org/jellis/pycon-ides.pdf , but aren't very useful absent video of the presentation itself. Hence this post.) PyDev PyDev has g...

Earlier, I wrote about how ORM developers shouldn't try to re-invent SQL . It doesn't need to be done, and you're not likely to end up with an actual improvement. SQL may be designed by committee, but it's also been refined from thousands if not millions of man-years of database experience. The same applies to DDL. (Data Definition Langage -- the part of the SQL standard that deals with CREATE and ALTER.) Unfortunately, a number of Python ORMs are trying to replace DDL with a homegrown Python API. This is a Bad Thing. There are at least four reasons why: Standards compliance Completeness Maintainability Beauty Standards compliance SQL DDL is a standard. That means if you want something more sophisticated than Emacs, you can choose any of half a dozen modeling tools like ERwin or ER/Studio to generate and edit your DDL. The Python data definition APIs, by contrast, aren't even compatibile with other Python tools. You can't take a table definition ...

I presented at the utah python user group last night. I gave an introduction to the PyDO2 ORM tool as well as the python DB API and psycopg. Most readers are probably most interested in the pydo2 section. Here's the slides: http://utahpython.org/data/python-and-databases.pdf . I briefly mentioned SqlAlchemy in the context of, "here's some stuff that SqlAlchemy does that pretty much nobody else can," but didn't have time to cover TWO ORM tools. It's worth having a look at though if you've reached the limits of what pydo2 et al can do.

Take Alex Martelli's Number class from the augmented assignment example in What's New in Python 2.0 : class Number: def __init__(self, value): self.value = value def __iadd__(self, increment): return Number( self.value + increment) >>> n = Number(5) >>> n That's not very pretty. Let's add a __getattr__ method and leverage all those nice methods from the int or float or whatever it's initialized with: class Number: def __init__(self, value): self.value = value def __iadd__(self, increment): return Number( self.value + increment) def __getattr__(self, attr): return getattr(self.value, attr) >>> n = Number(5) >>> n 5 Great, the __str__ method from our int is being used. Let's keep going with the example now: >>> n += 3 >>> n.value Traceback (most recent call last): File " ", line 1, in ? AttributeError: 'int' object has no att...

Glyph Lefkowitz cites me as an inspiration to write Why Axiom Doesn't Expose SQL . Alas, I disagree with most of what he says. My post was about how if you're writing a tool that presupposes the use of a relational database, it's stupid to try to protect your users from having to know SQL . (This also means I think projects that bend over backwards to pretend ALTER TABLE is too hard are misguided, as well. But that's another subject.) Glyph's first argument is that any form of SQL is an invitation to sql injection attacks. This particular form of scare mongering isn't appreciated. Come on: this is 2005. It's ridiculously easy to write injection-proof SQL, even by hand. Arguing that allowing SQL allows injection attacts is like arguing that coding in python allows "shutil.rmtree('/')": correct, but irrelevant. Glyph further claims that "interfaces should be complete things," and that this justifies trying to obliterate any ...

Spyce user Lars Schmidt created a Wikipedia article on Spyce. Nice! (Now I need to add a section on Active Handlers , which is one of the main things I think makes Spyce compelling for larger projects, as well as simplifying smaller ones.)

If you are writing an ORM tool, please keep this one point in mind: I already know SQL. Your new query syntax isn't better; it's just different. Which means one more thing for me to learn. Which means I probably won't bother, and will use instead an ORM tool that respects my time. Consider: if your target audience is like me, and already knows SQL, this should go without saying. Resist the temptation to be "clever" and overcomplicate things. If your target audience does not know SQL, then either they intend to learn SQL, because they're using a relational database and expect that non-python code or ad-hoc queries will be necessary at some point, or they have no intention of learning SQL, and all their data-access code will now and forever be in python, in which case they would be better off using Durus or ZODB or another OODB. Be honest with these people and everyone will be happier. Django does some cool stuff, but heaven help me if I ever had...

Trying to figure out why sometimes disk access on my test machine takes way, way too long -- 1000+ ms -- I wrote some test code. My threads ran a function that looks like this: write = [] def writer(): while True: start = time.time() f = tempfile.TemporaryFile() f.write('a' * 4000) end = time.time() write.append(end - start) Compare the times for max(write) on a machine with a SATA disk and on one with parallel ATA, where the given number of threads are run for a 10 second period: threads pata sata 1 6ms 6ms 2 400ms 11ms 4 1300ms 24ms Ouch. I admit I'm not a hardware nerd. Quite possibly I'm missing something, because even PATA shouldn't be THAT bad. Right? hdparm -i says for the PATA disk: /dev/hda: Model=ST380011A, FwRev=8.01, SerialNo=4JV59KZT Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63,...

I attended Paul Graham's Startup School this past Saturday. (Thanks to Drew Houston for letting me crash at his place!) I took fairly detailed notes on the speakers; I think this is the most comprehensive overview available, actually. (Note that these are in the order they actually spoke, which isn't quite the same as the plan .) Langley Steinert , entrepreneur. Short "entrepreneurship 101" talk. Lots of interesting Q&A. Marc Hedlund , Entrepreneur in Residence, O'Reilly Media. Talks about over a dozen startups he's seen in the last couple years -- most of which you'll recognize -- and why they succeeded. Qi Lu , VC at Yahoo. One subject: Why yahoo rocks. Total advertorial; skip this one unless you're a yahoo fanboy. Hutch Fishman , part-time CFO for startups. Talks about VC founds, directors, liquidity. Pretty basic stuff if you've read up on this at all, but his Q&A is worth reading. Paul Graham , author of entrepreneurship e...

Like many programmers (I suspect) who hear enough Lisp afficionados talk about how great their language is, I've given Lisp a try. Twice. I didn't make much headway on either occasion. For various reasons I was poking around python/lisp in google tonight and I came across this thread from a couple years ago. This crystalized it for me: now compare if x > y or a == 0: a1 = m * x + b else: a2 = m / x - b with (if (or (> x y ) (zerop a)) (setq a1 (+ (* m x ) b ) (setq a2 (- (/ m x ) b )). In this case, Lisp requires about 33% more typing, almost all parentheses. And, oh yeah, I forgot, aside from the parentheses, the pervasive prefix notation can be a drag. Syntax does matter. Everyone who has run screaming from a steaming pile of Perl understands this. Lisp's syntax isn't the train wreck that Perl's is; at the very least it's consistent. I could get used to it if there we...

As a (mostly ex-) Java programmer myself who prefers Python to Ruby, I'm puzzled by what seems like a rush of Java programmers to embrace Ruby as though it were the only dynamic language on the planet. I understand that it's mostly because of the success of Rails, which definitely came at the right time with the right marketing. But Ruby really doesn't seem like a good philosophical match with Java to me. Java, to a large degree, tried to be "C++ done right." That is, C++ without all the misfeatures that seemed good at the time but whose benefit turned out to not be worth the cost in complexity for developers. Java is a very orthogonally designed language; there is usually one obvious way to accomplish something. Python shares this. Ruby, OTOH, takes the C++ and Perl philosophy of "there's more than one way to do it," with predictible effects on maintainability. ("Perl," said a former co-worker to me yesterday, "is the drunken...

Brace you must Written it is, the Console. “Hello World” YODA the programming language

John, of course, writes the OS X reviews for ars technica. (If you haven't read these, you need to. His level of detail should make lesser reviewers think hard about finding another career.) In his blog, he's been talking about what Apple needs to do to avoid another Copland scenario , i.e., avoid resting on their OS X achievments only to wake up in 2010 and realize, "Oh crap! It's WAY easier to write apps for Windows than for OS X!" Which is a rather long introduction to the quote I liked so much: My instincts tell me that both C# and Java are too low-level. Yes, they both have fully automatic memory management, and both eschew C-style pointers for the sake of safety and security, which is more than can be said for Objective-C. But the runtime that Objective-C uses to do its "object stuff" is arguably higher-level than either C# or Java, both of which still seem to cling to charmingly retro notions of compile-time optimizations and "efficien...

Victor Moholy : A bad API, like a bad novel, feels like a trick: key information is withheld and simple relationships are hard to deduce. I had one of those "a-ha" moments reading this. ("A-ha," I thought. "I feel a rant coming on.") This is exactly why, after building probably one of the largest web applications done with OpenACS 3.2, I never managed to like the 4.x (and now 5.x) series of that toolkit. OpenACS 4.x and later suffer from Second-system syndrome . The effect is rather Zope-like: instead of a learning curve, you have a vertical cliff to scale before you can accomplish anything interesting. Add in bizarre and arbitrary api changes , it's no wonder nobody except the core team really got on board with the later OpenACS versions. (I suspect that the "everything must be a named parameter" had its genesis in the proliferation of functions taking over a dozen parameters. Deprecating all functions that don't require nam...

Everything looks like a nail. Some things just work better as a traditional app, guys.