I’ve really neglected to update the blog lately, but that’s at least in part because I’ve been busy doing preparations for talks - so you could /see/ me instead of read my blog! I’ll be speaking both at PyCon UK and PyCon Ireland, so if you’re going to either come chat with me! And, you know, maybe see my talks…
Also, I do have a proper blog post with actual content a-brewing, and I promise it will be done Real Soon Now ™.
Next year, in March, I will be at PyCon. It will be the third time I attend PyCon - ever since I attended my first, not going has not really been an option.
There are lots of good things about PyCon - meeting interesting people, seeing San Francisco, beating off recruiters with a stick, hanging out in the hotel bar and chill in the evenings - but the best part is that the talks are so many, and so good.
During EuroPython 2012, after my training and talks, I really needed to do some coding, so I started hacking on a ‘practical’ application of the AST - making (some) constants faster than local variables, instead of slower by inlining them on import.
To do this, I use a custom importer on meta_path to intercept the import, and find any assignments look like constants - that is, any module-level variable in ALL_CAPS that is a simple string or a number.
I had a blast at Europython - I made new friends, went to a couple of talks that gave me some ideas for the future, and my own talks seemed to go down well.
All in all, the EP2012 organization was great, the food was way beyond ‘normal’ conference fare, and the venue was good - although finding a place to sit down during lunch was hard.
I would have liked some kind of feedback mechanism in place for the talks - had I known there would be none I’d have arranged one for my own talks and especially the training session I held.
I enjoyed The Clean Coder by Uncle Bob, and would recommend it to any serious developer. I agree with almost everything in it, but there is one jarring exception - I disagree strongly with his view that because it’s your own responsibility to practice, you should not do it on paid time.
Under the headline “Practice Ethics”, he states: “Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you [.
This is a writeup of a talk I did recently at Software Passion Summit in Gothenburg, Sweden. For more background info, see the post I did prior to the conference.
Writing a specification in a full-blown programming language like Python has upsides and downsides. On the downside, Python is not designed as a declarative language, so any attempt to make it declarative (apart from just listing native data types) will require some kind of customization and/or tooling to work.
I have tried to do a full writeup of my PyCon experience this year, and failed miserably, so this is what I’ll do: This post will focus only on the conference experience - lessons learned, sessions attended, and projects discovered will have their own posts; this is the other stuff.
So what about the conference as a whole? It was, just like Atlanta last year, an overwhelmingly positive experience. This was the first time I volunteered, and I really felt that that was a given win - from getting to have a say in the program by joining the program committee, through doing a session as a session runner and getting to see all the work that goes on behind the scenes, to responding to a just-in-time tweet to join the swag-packing party.
My name is Fredrik, and sometimes I write code I’m not that proud of.
A friend of mine started on a Python project recently, and when I asked him to put it up on Bitbucket his response was an immediate and not-quite-mock “But then people will see my code!”. I believe this fear of showing one’s code is common, and I believe that it is a problem. Not so much for open source, or anything like that, but for the individual - it suggests a belief that your code isn’t good enough, that other people’s code is better, and/or that offering my code up for others to see will lead to rejection and ridicule.
Edit: got complaints that code was hard to read, trying out Pygments.
In part 1, we looked at sending functions as arguments to other functions, at nesting functinons, and finally we wrapped a function in another function. We’ll begin this part by giving an example implementation on the exercise I gave in part 1:
>>> def print_call(fn): … def fn_wrap(*args, **kwargs): … print("Calling %s with arguments: \n\targs: %s\n\tkwargs:%s" % ( .