Tag Archives: Python

Python in the Caribbean? More of this!

I don’t often make a point of blogging about the conferences I end up at, but sometimes there are exceptions to be made.

A couple of weekends ago, a happy set of coincidences meant that I was able to attend the first PyCaribbean, in Santo Domingo, capital city of the Dominican Republic. I was lucky enough to give a couple of talks there, too.

This was a superbly well-organised conference. Leonardo and Vivian were truly excellent hosts, and it showed that they were passionate about welcoming the world to their city. They made sure breakfast and lunch at the venue were well catered. We weren’t left wanting in the evenings either, thanks to organised outings to some great local bars and restaurants over each of the evenings.

Better still, the organisers were properly attentive to issues that came up: when the westerners (including me) went up to Leo asking where the coffee was at breakfast (“we don’t drink much of that here”), the situation was resolved within hours. This attitude of resolving mismatches in the expectations of locals vs visitors was truly exceptional, and regional conference organisers can learn a lot from it.

The programme was, in my opinion, better than by rights any first-run conference should be. Most of the speakers were from countries further afield than the Caribbean (though I don’t believe anyone travelled further than me), and the keynotes were all of a standard that I’d expect from much more established conferences. Given that the audience was mostly from the DR – or Central America, at a stretch – the organisers showed that they truly understood the importance of bringing the world’s Python community to their local community. This is a value that it took us at PyCon Australia several years to grok, and PyCaribbean was doing it during their first year.

A wonderful side-effect of this focus on quality is, the programme was also of a standard high enough that someone could visit from nearby parts of the US and still enjoy a programme of a standard matching some of the best US regional Python conferences.

A bit about the city and venue: Even though the DR has a reputation as a touristy island, Santo Domingo is by no means a tourist town. It’s a working city in a developing nation: the harbour laps up very close to the waterfront roads (no beaches here), the traffic patterns help make crossing the road an extreme sport (skilled jaywalking ftw), and toilet paper and soap at the venue was mostly a BYO affair (sigh). Through learning and planning ahead, most of this culture shock subsided beyond my first day at the event, but it’s very clear that PyCaribbean was no beachside junket.

In Santo Domingo, the language barrier was a lot more confronting than I’d expected, too. Whilst I lucked out on getting a cabbie at the airport who could speak a tiny bit of English, and a receptionist with fluent English at the hotel, that was about the extent of being able to communicate. Especially funny was showing up at the venue, and not being allowed in, until I realised that the problem was not being allowed to wear shorts inside government buildings (it took a while to realise that was what the pointing at my legs meant).

You need at least some Spanish to function in Santo Domingo, and whilst I wasn’t the only speaker who was caught out by this, I’m still extremely grateful for the organisers for helping bridge the language barrier when we were all out and about during the evening events. This made the conference all the more enjoyable.

Will I be back for another PyCaribbean? Absolutely. This was one of the best regional Python conferences I’ve ever been to. The organisers had a solid vision for the event, far earlier than most conferences I’ve been to; the local community was grateful, eager to learn, and were rewarded by talks of a very high standard for a regional conferences; finally, everyone who flew into Santo Domingo got what felt like a truly authentic introduction to Dominican Culture, thanks to the solid efforts of the organisers.

Should you go to the next PyCaribbean? Yes. Should your company sponsor it? Yes. It’s a truly legitimate Python conference that in a couple of years time will be amongst the best in the world.

In PyCaribbean, the Python community’s gained a wonderful conference, and the Caribbean has gained a link with the global Python community, and one that it can be truly proud of at that. If you’re anywhere near the area, PyCaribbean is worthy of serious consideration.

A friendly PyCon Australia 2013 Early Birds reminder

We’re down to just over 20 early bird registrations left of our original quota of 80. That means that we’ll probably run out of Early Bird tickets before our deadline of Friday.

The big announcement to every mailing list I can think of will happen tomorrow, so today’s a great chance to to get in before the tickets suddenly disappear.

Early Bird Registrations start at $165 for individuals, with discount registration available for students at $44. All the details are at the PyCon Australia 2013 web site.

Vale John Hunter, author of Matplotlib

In my BSc(Hons) thesis, which I submitted in 2010, I commenced the acknowledgements as follows:

First, a hearty thanks to people whom I do not know: The developers of Python, Numpy, Scipy, the Python Imaging Library, Matplotlib, Weka, and OpenCV; you have collectively saved me much boring work throughout this past year, for which I am truly grateful.”

So to hear of the sudden death of John Hunter, creator and maintainer of Matplotlib was truly saddening. Matplotlib is one of those pieces of software absolutely instrumental in Python’s takeup as a language in the fields of maths, the sciences and engineering. When I was a student, I’d find myself using Matplotlib very often — it was the best there is.

Tragically, John Hunter was in his mid-forties, and left behind a wife, and three young daughters. Numfocus has created a memorial fund to care for and educate his daughters. I’ll be contributing to this fund as a way of thanking the Hunter family for John’s contribution to my own work.

Fernando Perez of IPython fame has written up a substantial post about John’s contribution to the community. PSF member, and PyCon US chair, Jesse Noller has also written a tribute to John.

It’s a somewhat strange feeling — coming to realise the contribution of one person only after he died. Such is the way of Open Source — the impact of the tools we use and develop become more important than the people who develop them. And sometimes, developers are just happy to let things be that way.

One month until PyCon Australia 2012 (gulp)

As I’m busily sitting in the speakers’ room at OSCON 2012, I’m reminded that it’s not all that long until we kick off PyCon Australia 2012. I’m really looking forward to seeing two days of interesting, fun and informative talks from Australia’s best Python experts. I’m also really really excited about our two US-based keynote presenters: Mark Ramm (TurboGears co-BDFL, Pyramid hacker, and Engineering Manager on Juju at Canonical) and Kenneth Reitz (author of Python-Requests, various other Python open source projects, and Python Overlord at Heroku).

If you haven’t registered for the conference yet, we’d love it if you did: registrations will remain open until the week of the conference (unless we sell out); if you want T-shirts, you’ll need to register on or before July 31. More information can be found at the PyCon Australia website.

PyCon Australia 2012 starts here

PyCon Australia
So one thing I forgot to mention on this blog is that I’ve taken over the reins of PyCon Australia for the 2012 and 2013 conferences. After spending two formative years in Sydney, under the direction of Tim Ansell, Richard Jones et al., we’re taking the conference south to Hobart, Tasmania. We’ve got a great team, consisting of myself, Joshua Hesketh and Matthew D’Orazio, and our papers committee is being led up once again by Richard Jones.

So, what can you look forward to? Well, here’s what we know so far.

Wrest Point

We’re holding PyCon Australia around the weekend of August 18 and 19 2012. Our venue is the Wrest Point Convention centre in Sandy Bay.  We’re really excited about our choice of venue — as well as offering us perfectly-sized rooms for our conference, the wide variety of spaces in the complex allow us to bring all of the traditional PyCon Australia events — CodeWars, the sprints and the conference itself — under the same roof for the first time.

Wrest Point is situated on the shoreline of the River Derwent, and this not only admits excellent views from the conference venue, but will also enable us to run some truly memorable social events, including the conference dinner, which we hope to share more details about shortly.

Our venue also lets us offer accommodation across a very wide range of budgets (starting around $124/room/night) to our delegates — this is not just a nominated conference hotel, it’s in the same building complex as the conference venue. This means that delegates can stay on-site for the entirety of the conference.  We think this will prove very popular, especially amongst delegates sticking around for the conference sprints.

Hobart & Wrest Point

For students and those travelling on a budget — we plan on keeping the conference affordable: there’ll still be heavily discounted student tickets, and we’ll announce budget accommodation options when registration opens.

Finally, you might be wondering how you can help make PyCon Australia the perfect conference for you? Well, in the coming week, we’ll be opening a Call for Topics.  This is an opportunity for you, as a potential PyCon Australia delegate, to nominate both topics and presenters that you’d like to see at the conference.  By nominating presentations, you can help ensure that PyCon Australia can help you enhance your skills and increase your knowledge of Python.

Of course, if you have something that you could present at PyCon Australia, we’d love to hear from you as well.  We’ll be opening a traditional call for presentations during February.

So, that’s it for now.  I’ll be sure to keep you up-to-date on our progress as we seek to put on the best Python Conference that Australia can offer. If you’ve got something to ask, feel free to drop a comment, either here, on Twitter, or on our Google+ page — we’ll get back to you as quickly as possible!

(Photos: “Wrest Point” by JJ Harrison, CC-BY-SA; “View of Hobart CBD” by Aaroncrick, CC-BY-SA)

AUC /dev/world/2010 — I’m Presenting!

AUC /dev/world/2010, the Apple University Consortium’s conference for developers working on or with Mac or iOS devices is on again this year, on the 28th and 29th of September, in Melbourne.  Last year I presented a talk, and ran the conference’s lightning talks; the conference was fanstastic: the content was easily-accessible to staff and students from across the country, and catered to a very wide range of skill levels and familiarity with Apple frameworks.

This year, I’ll be presenting Awesome Things You’ve Missed in Python, a fast-paced, code-heavy recap of interesting features to hit the Python Programming language in the past few years.  My talk is not specific to Apple development, but will have a strong focus on techniques which are applicable to development with the PyObjC library.

If you’re on staff or are a student of an AUC member university (most Australian Universities are, as are a few Kiwi ones), registration is cheap ($100 for students), and all flights and accommodation are subsidised (to a generous limit).  If a fun two days of meeting interesting people and learning about development techniques with the latest technology available on Apple devices interests you, get in contact with your local AUCDF coordinator to register!

Pythonic UIs

I’ve just been reading Richard Jones’ current project, where he’s implementing a very Pythonic way of creating GUIs (for example, managing gui contexts using Python’s context managers). I’m very very excited, and I hope this sample code shows why:

with gui.form() as form: name = gui.row('Name', gui.text()) skill = gui.row('Skill level', gui.selection(['Awesome', 'Radical', 'Understated'])) @gui.submit('OK') def on_click(button): print 'Got name=%r'%name.value print 'Got skill=%r'%form['skill'].value gui.stop(0) @gui.cancel('Cancel') def on_click(button): gui.stop(1) 

Take a look at what this code does at Richard Jones’ weblog. It’s pretty awesome.

Cocomo: An experiment in metaprogramming in python

Friday saw the second edition of the UTAS Computing Society Lightning Talks, if you haven’t seen them already, I highly recommend that you check them out — this semester’s were at a very high standard indeed, and I wish I’d printed out more certificates for good talks :). My talk was a demonstration of using metaprogramming in Python, though that’s not what it seemed to be about.

An introduction

I went to the Apple University Consortium’s Cocoa Workshop at the University of New South Wales in February of this year, it was a heap of fun, and we learnt heaps whilst there. One of the key distinguising features of Cocoa is its use of verbose English method and attribute names, the idea being that each line of code should make a reasonable amount of sense when read aloud, hence:

NSString *str = [[NSString alloc] initWithString @"Hello World!"]

does indeed allocate memory to hold a string object, and initialises the newly-allocated memory with a string containing “Hello World!” (this code is highly redundant!). Supposedly such a naming scheme allows coders to write code that is easily maintainable by the original coder, and easily learnable by people who pick up the code for the first time.

On the other hand, my friends, collectively known as Maclab (named after the room at UTAS we inhabit) have developed a rather unique vocabularly, which in particular involves replacing as many words as possible with either ‘thrust’ or ‘fork’, so “Thrustingly thrust the forking forker” is not an uncommon utterance amongst my friends. If this is indeed their usual mode of conversation, then Cocoa’s way of identifying methods and attributes is not necessarily going to be a particularly intiuitive one. So, clearly, we need a version of cocoa that meets their needs.

The setup

So, conveniently, Apple provide a comprehensive version of the Cocoa API, thanks to the PyObjC project. We can therefore use the Python bindings for Cocoa facilitate our new version of Cocoa. Since Cocoa has a very consistent naming scheme, we can simply perform string replacement to translate from our maclab language to the standard cocoa language, using a routine somewhat like this:

 def translate(inp): ''' Translates an input string from key language to value language ''' for i in LANGUAGE: if i[0].islower(): inp = inp.replace(i, LANGUAGE[i]) inp = inp.replace(rtitle(i), rtitle(LANGUAGE[i])) else: inp = inp.replace(i, LANGUAGE[i]) return inp def rtitle(i): return i[0].upper() + i[1:] 

Here, LANGUAGE is a dictionary, with keys in the language code will be written in and values being the target language (in this case, Cocoa). There’s not all that much of a sophisticated nature going on in here. Now that we have a method by which we can translate our attribute accesses, we can get to the meat of the the code.

The implementation

To achieve the new API, we need to use a technique that I will call proxying. This involves the use of objects whose sole purpose is to intercept attribute accesses and calls to an underlying object. In this case, the point of intercepting the calls and accesses is to perform translation from our new objects to standard Cocoa objects. In Python we can do this by overriding the standard attribute access and call methods.

First up is __getattr__, the attribute accessor method — for this, we are passed a string; the name of the attribute that we’re looking for, which we translate, and then attempt to access upon the method on the underlying object (in this case, self.__u__). There is one slight hitch: in certain cases, we may not want to translate the attribute name. This is true, in particular, of the attribute that represents the underlying object. Hence we provide a REAL_ATTRS list, for which we use the default __getattr__ method for. This results in code that looks something like this:

 def __getattribute__(self,name): if name in REAL_ATTRS: return object.__getattribute__(self,name) else: new_objectname = "self.__u__.%s" % translate(name) new_object = eval(new_objectname) return CocomoProxy(new_object) 

Notice that we use eval to perform the lookup? It turns out that __getattr__ doesn’t work universally, whereas . notation does — so we use that for less failover.

Being able to call methods on the objects is important, but slightly more difficult — we want behaviour to be maintained, so we need to make sure that proper Cocoa objects are passed as arguments, rather than the Proxy objects that you may have originally dealt with. We can do this with Python’s argument unpacking — we build up a list of arguments, and unproxy them as necessary:

 def __call__(self,*a, **k): new_a = [i.__u__ if type(i) == CocomoProxy else i for i in a] new_k = dict( (translate(i), k[i].__u__ if type(k[i]) == CocomoProxy else k[i]) for i in k) return CocomoProxy(self.__u__(*new_a,**new_k)) 

We may also need to deal with iterators. This can be done using a standard generator function, thusly:

 def __iter__(self): for i in self.__u__: yield CocomoProxy(i) 

Finally, there may be legitimate reasons for extracting Cocoa objects, these include printing strings, so we provide an accessor method called no_really:

 def no_really(self): return self.__u__ 

And that’s the entire implementation! The final thing we need to do is provide a pre-proxied version of the base module for Cocoa. Let’s call it GypsyMagic.

The payoff

So now that we have a working bridge from Maclab English to Cocoa English, we can take this sample code that puts some stuff into an array, and then prints it:

 import AppKit hworld = AppKit.NSString.alloc().initWithString_("Hello, World!") arr = AppKit.NSMutableArray.alloc().init() arr.addObject_(hworld) arr.addObject_("Boop!") for i in arr: print i 

And write it in the far more palatable:

 from cocomo import GypsyMagic hworld = GypsyMagic.OGMouthWords.subsume().makeGogoWithMouthWords_("Hello, World!") arr = GypsyMagic.OGForkableTrinketHolder.subsume().makeGogo() arr.thrustinglyThrustForker_(hworld) arr.thrustinglyThrustForker_("Boop!") for i in arr: print i.no_really() 

If you’re interested in seeing how it all fits together, see Cocomo’s website.

Fun with Sockets

Whilst doing some coding today for my semester research project I found a need to check for incoming data on a socket without taking any data out of the stream. Here’s the code I came up with:

 cp.sock.setblocking(False) try: cp.sock.recv(0) stuffwaiting = True except socket.error: stuffwaiting = False cp.sock.setblocking(True) 

This code works finely on Linux — you can only receive data if there is data to be received (even if you want to receive no data). Unfortunately, the code doesn’t port to Mac OS — you may receive as many bytes as there are in the socket’s buffer — if there are no bytes in the buffer, you can receive 0 bytes. Therefore, the following fix is necessary:

 cp.sock.setblocking(False) try: cp.sock.recv(1, socket.MSG_PEEK) stuffwaiting = True except socket.error: stuffwaiting = False cp.sock.setblocking(True) 

So, my question for Lazyweb is: is there a better way to do this?