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

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.

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)

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!

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.

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.

 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?

Linux.conf.au 2009 is to be held at the University of Tasmania's Sandy Bay campus in Hobart, Tasmania over the week of January 19-24; and the call for presentations [1] and mini-confs [2] is now open. I am currently in the process of producing a proposal for a Python Miniconf to be held at LCA, so I thought I should detail my plans to a greater audience for the purpose of feedback/suggestions. The miniconf would be a single-day conference on the broad topic of Python programming.  Broadly speaking, the topics I would like to see presented would range through: - Recent developments on Python core (presented to a more Python-oriented audience than may happen at LCA proper) - Frameworks and libraries (e.g. Django, which I believe is hitting 1.0 this year) - Techniques of Python programming (e.g. using advanced/new/etc features of Python effectively) - Discussions of Python use in the "real world" (e.g. Industry use, education, etc, etc, etc). - Anything else Python-related: please make suggestions! [3] The intention is that there would be 5 "organised" talks of ~45 minutes length (although if there is sufficient interest/free space, I could split blocks into 2x25 minute talks), with a 50-minute block of lightning talks to conclude the event, with the possibilty of some loosely-organised get-together of pythoners after the day's proceedings have finished. If you are interested in participating in the Python miniconf (which requires you to also be interested in attending Linux.conf.au), please e-mail me [3].  I would particularly like topics of talks that people would be able to give (vague/general is fine at this early stage in preparation), so that I can include them in the miniconf proposal (so the earlier I receive them the better!). Thanks in advance for any help that you may be able to offer me. -- Christopher Neugebauer P.S. if I have missed any user groups/potentially interested parties, could you please forward this message on -- I've already dealt with most relevant mailing lists in Australia, but international lists may also be interested, due to the nature of LCA as an international conference. [1] http://marchsouth.org/media/news/6 [2] http://marchsouth.org/media/news/15 [3] for the benefit of google groups users: chrisjrn [ a t ] gmail.com 

TUCS Tech Talk #1, originally uploaded by Christopher Neugebauer.

As I mentioned previously, TUCS had its first tech talk on Friday (delivered by myself, on the topic of Introductory Python), this is the first opportunity to show off photos from it. I was rather impressed by the turnout (there are a few people off to the side that can’t be seen in the frame).

The Membership front was fairly successful, given that we managed to sign up somewhere in the order of 7 new members (which is not bad given how late in the semester it is, and that we weren’t offering Alcohol at the event ), hopefully we can get a few more before the end of the semester, as it would be nice to get some people who aren’t part of the “usual crowd” to join in.

The main reason for this post was that I delivered the tech talk, on the topic of Introductory Python. Overall, I think it went fairly well, although I mistimed the talk such that I had to completely miss one section of the talk (which is a reminder of my debating days… but let’s not get into that). Anyone who wants to comment on my talk (except for the sections where Bruce crashes — I already know about this) is quite welcome to — it’s available in its entirety at Google Video

The day was quite successful. Here’s hoping that TUCS can keep getting stronger!