Look at this little fella – isn't he cute! Taken this morning amid preparations for wassailing in the orchard.
Another 'what I had for dinner' post. Sorry.
I've spent a bit more time learning Python, because I've been dabbling with Google App Engine (which I'm going off rapidly) but mainly because it's an interesting language. What's particularly intriguing to me is its similarity to Ruby, and hence where it differs in syntax or approach makes for a notable point of comparison. Of course it's probably more correct to say that Ruby is similar to Python than the other way around. From my still very small exposure to Python…
- Less confusion with the way classes work. Or maybe I just haven't stumbled into Python's equivalent of meta-classes and class vs instance variables.
- @classmethod is a much neater way of stating what's a class method rather than an instance method, compared to all that self gubbins, or the dreaded <<.
- Optional named arguments for functions, allowing more flexibility for optional arguments and greater clarity when calling. [As an aside I like Objective-C's way of building argument labels into the method signature, but not it's square brackety syntax: [obj message:foo]. I'd much rather do obj.message(foo) and in fact with properties in Objective-C 2.0 we see more of this style.]
- I think I probably prefer explicit return statements rather than the Ruby way of returning the last evaluated thing in any expression.
- List comprehensions. To start with it just seems like a syntactic difference – Python: [x*2 for x in my_list] Ruby: my_list.map {|x| x*2}. But Python's party trick is excluding elements as it goes: [x*2 for x in my_list if x != 3].
Nasty things about Python:
- Seriously – indentation to demarcate blocks? Apparently I'll get used to it.
- Double underscores. __init__ is a complete pain to type. Why not just a single underscore at the start or something?
- Fiddly module system. Why the need for an __init__.py file in a directory, just to make it a module? Why the need to explicitly define an __all__ method just to be able to import everything in a module? I want to be able to create a "model/" directory, put all the .py files for my DB classes in there, then import the whole lot from my other classes with ease. When I add a new model class, I shouldn't have to go and modify the __init__.py file. It seems to be a real pain to split code up into multiple files sensibly in Python. If I've missed a trick here – please somebody show me the light!
- The string interpolation is OK I suppose, giving the full power of C style formatting, but most of the time you're just doing simple interpolation and Ruby's syntax is far more pleasant and readable. Python: "Hello %s, from %s." % (person, greeter) Ruby: "Hello {person}, from {greeter}." Ruby also has a full on formatting system for the few times when you need it.
Episode three in my curry cooking adventure – this time with vegetables! See parts 1 and 2 for the exciting initial chapters. I've finally used up all the garlic and ginger paste I made for the first one.
I was stumbling along in the gloom of another grey day at the WWA. And at 3:30pm it was starting to get dark. Very poor conditions for wildlife photography! Then I noticed a small blue bird on a branch and bingo, there was one of the kingfishers in a spot I'd never seen it before, and handy for me to rest my camera on the rail of a bridge only about 8m away. Here are the best couple of shots I got (the first was actually entirely handheld).
A light but fairly complex taste that's reasonably bitter and hoppy, with a slightly burnt/roasted edge which I'd only usually expect to fine in dark beers and stouts. The bitterness and 4.3% ABV make it highly quaffable, but maybe it's a shade too bitter not to get wearing after a while.
Having ploughed through much of the documentation, done the tutorial and started writing my own little web app, I have some half-formed thoughts about Google App Engine to throw out to the world.
- As far as I can tell, any sort of data aggregation functionality (counting, averaging etc.) just won't be possible as the Datastore APIs don't allow for it. I've tried to think of ways to fake it but even my most elaborate machinations come up against the buffers. The only way to manage it at all is to do counting and averaging piecemeal, manually keeping the aggregate values you need up to date with each individual entity modification. Unfortunately, that means that you can't introduce new functionality requiring new aggregate values after you've already got a million users, because you've missed the chance to record those aggregates along the way.
- Python's OK, but I don't like using indentation as the sole way to define blocks. But I'm sure I can get used to that.
- I really don't like having to put an empty __init__.py file in any subdirectories of my python code. If I don't do that it seems I can't import foo.bar.Thingy. Breaking up code into multiple files in a sensible directory structure is surely a fairly common thing to do, so I'm amazed that Python makes it strangely difficult. I hope I've simply missed something and it's actually easier than that.
- In fact all those double underscores look horrid and are a pain to type. Surely a single underscore would have been quite adequate?
- The overall experience for learning GAE is very sorted. Smooth and well integrated – all you need to supply is your own decent text editor. I'm trying out TextMate, the darling of Mac OS X code editors, but I'm worried to see that it doesn't seem to have been updated for over a year.
It seems to be the done thing these days to learn how to use Google App Engine (and thus Python) within a couple of hours and then hack out a simple web application to prove how easy it is.