Spyced

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.

Michael Sica wrote a post about his experience writing a project manager . Java, cool I get it. JSP, there's like 3 different ways to do everything. Which do I learn. Application frameworks, started learning Struts - what a nightmare. Stared learning JSF - what a nightmare. Found Spring and Spring MVC, and they rocked. Crap, I need to learn Tiles too. Ok, so how does Tiles work with Spring MVC. Ok that's, cool. I only need to do 6 things everytime I make a form. (I actually have a list printed out so I won't forget all the steps.) Life's too short. Choose to be productive. Choose Python .

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas...

Makes me wish I had time to work on a 3D game.

I'm sure being described as "an openlazlo blogger" is probably not what he had in mind, but Michael Sica of Ataraxis Software has written more about it than I've seen anywhere else. Here's his first post on the subject , from July. Around a half dozen more follow. OpenLazlo , you will recall, is a rich web app platform that uses Jython internally . (Warning: PDF.) (Michael's blog is also interestiing from an entrepreneurial standpoint. Starting your own company is a common fantasy for developers, and Michael is doing it. I'm catching up on the archives now.)

(Today's questions are very CPython-specific, but that hasn't stopped me before. :) I spent some time today looking for the source of a bug that caused my program to leak memory. A C module ultimately proved to be at fault; before figuring that out, though, I suspected that something was hanging on to data read over a socket longer than it should. I decided to check this by summing the length of all string objects: >>> import gc >>> sum([len(o) for o in gc.get_objects() if isinstance(o, str)]) 0 No string objects? Can't be. Let's try this: >>> a = 'asdfjkl;' >>> len([o for o in gc.get_objects() if isinstance(o, str)]) 0 So: (Easy) Why don't string objects show up for get_objects()? (Harder) How can you get a list of live string objects in the interpreter?

(March 2006: you may also be interested the updated review I did for PyCon -- http://spyced.blogspot.com/2006/02/pycon-python-ide-review.html .) For September's meeting, the Utah Python User Group hosted an IDE shootout. 5 presenters reviewed 6 IDEs: PyDev 0.9.8.1 Eric3 3.7.1 Boa Constructor 0.4.4 BlackAdder 1.1 Komodo 3.1 Wing IDE 2.0.3 (The windows version was tested for all but Eric3, which was tested on Linux. Eric3 is based on Qt, which basically means you can't run it on Windows unless you've shelled out $$$ for a commerical Qt license, since there is no GPL version of Qt for Windows. Yes, there's Qt Free , but that's not exactly production-ready software.) Perhaps the most notable IDEs not included are SPE and DrPython. Alas, nobody had time to review these, but if you're looking for a free IDE perhaps you should include these in your search, because PyDev was the only one of the 3 free ones that we'd consider using. And if you aren...

I tried my hand against around 5000 other programmers in Google's Code Jam 2005 . Last year Windows corrupted the hell out of itself halfway through, when I had foolishly not saved any work. The time and concentration lost rebooting killed me. (I had the infamous anti-aliasing problem for my 500pt question. The lowest qualifying score from that group was in the 170s, IIRC. Google dialed down the difficulty considerably this year.) This year I went into battle armed with Visual Studio 2005. TopCoder doesn't recognize any of the beta additions, but Studio 2005 has a pretty decent Emacs mode. Instant 10% productivity bonus! The alert reader will have already noted the use of the past tense in the first sentence and concluded that I didn't make it into the top 500 to qualify for the next round. Correct; I missed the cut by 4 points (732 to the 100th place guy's 736). Ouch. I'd kinda rather have been way outclassed than lose by 4 points out of 1000. Now I...