Showing posts with label Python. Show all posts
Showing posts with label Python. Show all posts

Monday, July 21, 2008

OSCON: Python in 3 Hours

While I've written stuff in Java, Python and half a dozen other languages, I'm a Perl guy. My first solution to a programming problem is to use Perl. This hasn't always been the case of course, I used to be a Fortran guy after all, and my solution to most things would be to crank out some Fortran. I'm more or less language agnostic, and try and pick the right tool for every job, it's that so many jobs can be done easily in Perl.

However I've learned Python several times now, used it for whatever project I've needed it for, and then mostly forgotten most of what I knew about it afterwards. But with the release of Google's App Engine however, I think it's time to dust my Python off and pick it up again for a third time. Which is why I'm sitting in "Python in 3 Hours" given by Steve Holden. Steve has put his slides online, but it looks like his hosting provider isn't holding up that well...


Update: The main principle in Python is "Keep it simple stupid", as opposed to Perl's "There is more than one way to do things". That basically sums up the difference between the two languages. It looks like Twitter is over capacity again, the fail whale is very much in evidence.

Update: One of the things that people coming from the C world find difficult is that while Python is a strongly typed language the type is associated with the value, not with the variable. Well that and the mandatory indenting.

Steve is really emphasising the presence of the interactive interpreter, which is something that Python talk about a lot. As a Perl person, it's not something we really have, and I've not felt that lack. Trying to get my head around why Python people feel it's important.

Update: Steve is talking about the different implementations of Python. Also not something we've had with Perl, at least until Perl 6 came along...

Update: That's interesting. Since Python 2.5 integers are unbounded, and since Python 3.0 diving two integers no longer does integer division, you end up with a floating point number. Oh, and strings are going to become Unicode by default.

Update: Now here is something I've always wanted in Perl, and it doesn't have because of its admittedly quite odd object model, default methods on strings; s.lower(), s.upper(), s.strip() and the like. Of course since strings are immutable, they don't do an in place operation.

Having things like strings and tuples, and dictionary keys, as immutable is one of the things I've always had problems with in Python, and yes I know it means it's all thread-safe. Guess I've been working with Perl's threading model too long as well...

Update: Interesting, if obvious, admission from Steve,

We're talking about a Turing complete language, so there is always more than one way of doing things...
when talking about there being only one way of doing things in Python.

Update: The print statement is actually going away in Python 3.0, replaced by the print function. Which, yes, makes a big difference. That's a subtle but fairly fundamental change. Have to think about that for a bit...

Update: Time for morning coffee, back after these short messages...

Update: ...and we're back, and Steve has moved on to defining functions, where Python is actually a lot different than most other languages. In Python def is an executable statement. The interpreter reads and compiles the indented body and the resulting function object is bound to the function name in current namespace.

Update: After working with Perl for so long I've never liked the way Python handles variable parameter lists,
Some functions can take an indefinite number of positional and keyword arguments. These are caught with a special parameter syntax; *name becomes a tuple of "extra" positional arguments to a call **name becomes a dict of "extra" keyword arguments to a call: n=v becomes {n: v}
which is only sort of like the way Perl does things...

Update: Pointer to PEP8, the "Style Guide to Python". I guess Perl people just have "Perl Best Practices" by Damian?

Update: Must admit I'm starting to drift here...

I'm trying to figure out whether Python is more strict and complicated than Perl, or whether I'm just thinking in Perl, and Python is just as slack and easy to use as Perl but in a different way? Anyone got any opinions on that one?

Update: I didn't realise the Python interpreter implicitly provides a $self when using an instance. That's interesting...

Update: Steve just said,
Five minutes left to cover formatting and I/O...
That's not good. Nor is the fact that it's only in "modern" Python that you can iterate over a file and don't have to read it in all at once. Hmm...

Update: ...and we're done, or at least I am. Time for lunch.

Tuesday, April 08, 2008

Google App Engine

Over the last couple of weeks there have been rumours running around that Google would be launching something to directly compete with Amazon's AWS suite, and embed themselves even further into the Cloud. Sure enough, while I was asleep, Google announced a preview release of Google App Engine at Campfire One.


But what Google has done is take a totally different approach to Amazon. The Google App Engine is basically a platform for producing and deploying (robust and scalable) webservices, where as Amazon's offering is a more pick and mix affair with storage (S3) and compute (EC2) and databases (SimpleDB) being offered as components rather than being integrated into a single platform.

However, one of the reasons why Amazon's S3 storage service has taken off so rapidly is the fact that it can be viewed as a component, and startups (and much larger firms) can use it transparently. So long as you wrap the service sensibly, if Amazon went bust tomorrow (unlikely) or the service became unavailable or unreliable (slightly more likely, but still unlikely) you wouldn't have to rewrite your entire code base. You buy a whole bunch of servers, assuming you can afford it, rewrite the low level library that handles storage, and you're set. You still maintain control.

Google isn't offering as much control as Amazon, if you build your business on Google's platform you're relying on Google to support your business. It's an interesting choice from Google's point of view, and it'll be interesting to see whether people will bet on Google. It looks like a sure bet, but if I was investing a lot of money into a business I must admit that it would probably make me rather nervous to leave so much control in the hands of another company who of course have their own objectives.

It seems very clear that, unlike Amazon's EC2, the App Engine doesn't have the potential (at least in its current incarnation) to be a general computing platform, it seems to be specifically built to be request driven, and that's okay.

Google's choice of Python as its runtime is probably fairly predictable, when you work for Google you have to use one of the four allowed languages, at least for deployable code, those being C++, Java, Python or JavaScript. Of the four Python is the obvious choice...

While I'm not a Python person, my language of choice to get things done is Perl, due to circumstance I've actually had to write a bunch of Python before. So while I'm not a guru, I can get things done in Python, abet slowly, all the while muttering that I'd get it done faster if I was writing in Perl. So I've put myself into the wait list for a slot in the preview release. I'll let you know if get accepted before they open the doors properly, I guess it'll take a while though...


However the release of Google's App Engine does mean that I'm even more annoyed than I already was, which was fairly, that my travel budget won't quite stretch to a trip out to San Francisco for Google I/O. I've already had to shelf plans to head out for Where 2.0 due to the budget squeeze here in the UK, although since I've already been out to ETech this year and will be heading to OSCON in July maybe I shouldn't complain? My a Dopplr trips list is still looking fairly full after all...

Update: There is some good discussion of Google's new App Engine by Richard MacManus over at Read/Write Web and by Brady Forrest on the O'Reilly Radar, and TechCrunch have had a go at building and launching an application using the new framework.

Update: Guido van Rossum talking about Google App Engine at it's release via Robert Scoble (and QIK) in two parts...

I'd have loved to have seen Larry Wall doing one of his typical off the wall talks at the launch of Google App Engine with a Perl run time. But I guess you can't have everything...

Update: Show your support for Perl as the next language runtime to be added to the App Engine. Right now (10/Apr) this is the second most highly ranked support request, just behind support for urllib and urllib2 interfaces in Python. Surely we can do better than that?

Update: Well, so much for the lock in arguement (via Daring Fireball and the O'Reilly Radar)